canonical: https://jentic.com/apis/azure.com/redismanagementclient

# Microsoft Azure RedisManagementClient

Jentic publishes the only available OpenAPI specification for RedisManagementClient, keeping it validated and agent-ready. The API manages Azure Redis Cache resources under Microsoft.Cache, covering the full lifecycle of cache instances along with firewall rules, patch schedules, geo-replication via linked servers, access-key rotation, RDB import and export, and forced reboots. It is the control-plane surface for every aspect of running a managed Redis on Azure short of the Redis protocol itself.

## For AI agents

Provision Azure Redis Cache instances, rotate access keys, configure firewall rules and patch schedules, and link servers for geo-replication.

## Scope

Does not run Redis commands, manage cluster shards from inside Redis, or query keys - use for the Microsoft.Cache control-plane lifecycle, firewall rules, patch schedules, linked servers, and access keys only.

## Capabilities

- Provision an Azure Redis Cache instance with a chosen SKU and capacity
- Rotate primary or secondary Redis access keys without downtime
- Configure IP firewall rules that restrict access to a Redis cache
- Schedule weekly patch windows for a Redis cache instance
- Link a secondary Redis cache for geo-replication failover
- Import or export Redis data via RDB files in Azure Blob Storage
- Force a reboot of one or more Redis cache nodes for testing

## Use cases

### Provision a managed Redis cache

Application teams need a managed Redis instance for session caching, leaderboard data, or rate-limiting counters. The API provisions the cache at the chosen SKU and capacity, returns the access keys, and exposes firewall and patch-schedule endpoints so the cache can be hardened before traffic arrives.

Example prompt: Create an Azure Redis cache 'cache-prod-eu' at SKU Standard C2 in resource group 'cache-rg' in West Europe with non-SSL port disabled

### Access key rotation

Redis access keys are long-lived secrets used by application code, so they need to be rotated on a schedule and after suspected compromise. The API exposes listKeys and regenerateKey on each cache so rotation can be staged across the application without downtime.

Example prompt: Regenerate the secondary access key for cache 'cache-prod-eu' and return the new value for the application config

### Geo-replication via linked servers

Production workloads that need cross-region failover can pair a primary and secondary Redis Premium cache as linked servers. The API manages the linked-server resources under each cache so the geo-replication relationship can be created, inspected, and torn down through automation.

Example prompt: Link cache 'cache-prod-westus' to 'cache-prod-eastus' as the secondary, then verify the link state is Succeeded

### Patch schedule and forced reboot for resilience testing

SRE teams test failover behaviour by setting a known patch window or by forcing a reboot of the primary node. The API exposes patchSchedules at default scope and a forceReboot endpoint that targets specific shards or roles, so resilience testing can be scripted and rerun on demand.

Example prompt: Set a Sunday 02:00 UTC patch window on cache 'cache-prod-eu' and force a reboot of the primary node afterwards to validate failover

### Agent-driven Redis automation

An AI agent fronting an internal cache provisioning portal accepts a workload's requirements, validates the desired cache name, provisions the cache, configures firewall rules from the workload's allowlist, and stores the access key in the workload's secret store. Jentic isolates the AAD client secret so the agent only sees scoped bearer tokens.

Example prompt: Given a workload spec (name, region, SKU, allowed CIDRs), provision the cache, add firewall rules, return the primary access key

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| PUT | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{name} | Create or update a Redis cache |
| GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{name} | Get a specific Redis cache |
| POST | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{name}/listKeys | List access keys for a cache |
| POST | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{name}/regenerateKey | Regenerate an access key |
| PUT | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{cacheName}/firewallRules/{ruleName} | Create or update a firewall rule |
| PUT | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{name}/patchSchedules/{default} | Set the patch schedule on a cache |
| POST | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{name}/forceReboot | Force a reboot of the cache |
| PUT | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{name}/linkedServers/{linkedServerName} | Link a secondary cache for geo-replication |

## Key resources

- **Redis Caches** — Provisioning, listing, update, delete, and key listing/regeneration of Azure Redis Cache instances
- **Firewall Rules** — Per-cache IP firewall rules that restrict client access
- **Patch Schedules** — Weekly maintenance windows for cache patching
- **Linked Servers** — Geo-replication pairings between primary and secondary Premium caches
- **Import/Export** — RDB import from and export to Azure Blob Storage

## Why Jentic

- **Setup:** Wiring the RedisManagementClient by hand means registering an Azure AD app for OAuth 2.0, acquiring bearer tokens against management.azure.com, and polling the long-running cache create, import, and export operations yourself. Through Jentic you install once, import the RedisManagementClient from the API Directory, store the Azure AD credential once, and your agent calls it.
- **Permission scoping:** The subscription, resource group, and cache name travel in the URL path (/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Cache/Redis/{name}/...), so a rule can pin your agent to one cache and the operations it needs, such as reading the cache and configuring firewall rules. You choose the operations it may call, so destructive ones like regenerating an access key or forcing a reboot are not included unless you add them.
- **Credential handling:** Your Azure AD OAuth 2.0 credential is stored once, encrypted, by your own Jentic One instance and a scoped bearer token is injected at execution time. The client secret and any returned Redis access keys never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'provision an azure redis cache' or 'rotate a redis access key', and Jentic returns the matching operation with its input schema so the agent supplies the subscription, resource group, name, location, and SKU without browsing the reference docs.

## Related APIs

- **Storage Management Client** — Provisions the storage accounts that hold the RDB files used by Redis import and export
- **Cosmos DB** — Globally distributed NoSQL database with a Redis-compatible API surface
- **SQL Management Client** — Manages the Azure SQL databases that Redis is often used to cache in front of

## FAQ

### Why is there no official OpenAPI spec for RedisManagementClient?

Microsoft Azure does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call RedisManagementClient via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Azure Redis Management API use?

The API runs through Azure Resource Manager and uses OAuth 2.0 bearer tokens issued by Azure Active Directory under the azure_auth scheme with the user_impersonation scope. Through Jentic, the AAD client secret is held in the encrypted vault and a short-lived access token is supplied at execute time so the secret never appears in the agent's context.

### Can I rotate Redis access keys without downtime?

Yes. Use POST .../Redis/{name}/regenerateKey to regenerate one of the two keys while applications continue to use the other. Once the application has switched, regenerate the second key as well. The listKeys POST endpoint returns the current pair.

### What are the rate limits for the Azure Redis Management API?

Azure Resource Manager applies subscription-level read and write throttles (around 12,000 reads per hour and 1,200 writes per hour per region per subscription) and returns 429 with a Retry-After header when exceeded. Cache create, update, import, and export are long-running operations and should be polled with backoff.

### How do I provision an Azure Redis cache through Jentic?

Search Jentic for 'provision azure redis cache', load the schema for PUT .../Microsoft.Cache/Redis/{name}, then execute with subscriptionId, resourceGroupName, name, location, and an sku block. The pip install jentic Python SDK uses the async search, load, execute pattern.

### Is the Azure Redis Management API free?

There is no per-call charge for the management API itself; you pay for the Redis cache SKU and capacity by the hour. Premium SKUs are billed higher than Basic and Standard but are required for features like linked-server geo-replication, persistence, and clustering.

### Can I limit what my agent is allowed to do with the Redis Management Client API?

Yes. Because you run Jentic One yourself, your own rules decide which operations and credentials the agent may use, and the subscription, resource group, and cache name all travel in the URL path, so a rule can pin the agent to a single cache. You pick the operations it may call, for example reading a cache and configuring its firewall rules, while leaving out destructive ones like regenerating an access key or forcing a reboot unless you explicitly add them. The Azure AD credential is stored once by your own instance, and only a scoped bearer token is supplied at execution time so the client secret and returned Redis access keys never reach the agent's context.