canonical: https://jentic.com/apis/azure.com/searchmanagementclient # Microsoft Azure SearchManagementClient Jentic publishes the only available OpenAPI specification for SearchManagementClient, keeping it validated and agent-ready. The Azure Cognitive Search ARM control plane API provisions, scales, and manages search service resources inside a subscription. Agents can create or delete a search service, change its replica and partition counts, regenerate admin keys, mint or revoke query keys, and check name availability before creation. This is the lifecycle API behind any Cognitive Search deployment. ## For AI agents Provision Azure Cognitive Search service resources, scale replicas and partitions, and manage admin and query keys at the ARM control plane. ## Scope Does not query indexes, define index schemas, or run indexers - use for provisioning, scaling, and credential management of search services only. ## Capabilities - Create or delete a Cognitive Search service in a resource group - Update a search service's replica and partition counts to scale read or storage capacity - Regenerate primary or secondary admin keys to rotate credentials - Mint and revoke query keys scoped to specific applications - List query keys configured against a search service - Check whether a search service name is globally available before creation ## Use cases ### Search Service Provisioning at Scale Platform teams use SearchManagementClient to provision Cognitive Search services as part of an environment template. The PUT operation accepts SKU, replica count, partition count, and host mode, returning a long-running operation handle. Multiple services can be provisioned in parallel under the same subscription, each landing in its own resource group with its own admin and query keys. Example prompt: PUT /subscriptions/{subscriptionId}/resourceGroups/{rg}/providers/Microsoft.Search/searchServices/{name} with sku=standard, replicaCount=2, partitionCount=1 and poll until provisioningState is Succeeded ### Capacity Scaling for Read Throughput When query volume rises, SREs scale a Cognitive Search service horizontally by increasing its replica count. The PATCH endpoint accepts the new replicaCount and partitionCount, and Azure handles the rebalance. Partitions scale storage; replicas scale query throughput. Both can be raised independently up to the SKU's ceiling. Example prompt: PATCH the search service with replicaCount=4 to double the read throughput of the existing service ### Key Rotation for Compliance Security teams rotate Cognitive Search admin keys on a regular cadence. The regenerateAdminKey POST takes either primary or secondary as the key kind so callers can rotate one key while applications continue to use the other. Query keys can be created and revoked individually so per-application credentials never get reused across teams. Example prompt: POST regenerateAdminKey with keyKind=primary on service mysearch and confirm the new key value is returned in the response ### Agent-Driven Search Provisioning via Jentic Through Jentic, a platform agent can search for provision azure cognitive search, load the search service PUT schema, populate it with SKU and capacity parameters, and execute the call with a managed Azure OAuth token. The same flow can mint query keys and pass them to the data plane SearchIndexClient operations, all without exposing raw secrets. Example prompt: Search Jentic for provision azure cognitive search, load the search service PUT schema, execute it with sku=basic and replicaCount=1, then call createQueryKey to mint a key for the application ## Key endpoints | Method | Path | Description | | --- | --- | --- | | PUT | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Search/searchServices/{searchServiceName} | Create or update a search service | | PATCH | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Search/searchServices/{searchServiceName} | Scale replicas or partitions | | POST | /subscriptions/{subscriptionId}/providers/Microsoft.Search/checkNameAvailability | Check service name availability | | POST | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Search/searchServices/{searchServiceName}/listAdminKeys | List admin keys | | POST | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Search/searchServices/{searchServiceName}/regenerateAdminKey/{keyKind} | Regenerate an admin key | | POST | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Search/searchServices/{searchServiceName}/createQueryKey/{name} | Create a query key | ## Key resources - **SearchServices** — Cognitive Search service resources at the ARM control plane; supports CRUD and scaling - **AdminKeys** — Admin keys with regenerate and list operations - **QueryKeys** — Per-application query keys with create, delete, and list operations ## Why Jentic - **Setup:** Wiring SearchManagementClient by hand means registering an Azure AD app, running the OAuth2 azure_auth token exchange for the management.azure.com audience, and building the ARM long-running-operation polling loop plus the key-management endpoint shapes. Through Jentic you install once, import SearchManagementClient from the API Directory, store the Azure service principal credential once, and your agent calls it. - **Permission scoping:** SearchManagementClient puts the subscription, resource group, and search service name in the URL path (.../searchServices/{searchServiceName}), so a rule can pin your agent to one search service. You choose the operations it may call, so destructive ones like regenerating an admin key or deleting the service are not included unless you add them. - **Credential handling:** Your Azure service principal credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'provision an Azure Cognitive Search service' or 'scale a search service to more replicas', and Jentic returns the matching SearchManagementClient operation with its input schema across service CRUD, scaling, and key management. ## Related APIs - **Azure SearchIndexClient** — Data plane API that queries and indexes documents in services this API provisions - **Azure SearchServiceClient** — Data plane API that defines the indexes and indexers running inside the service - **Azure ResourceManagementClient** — Provisions the resource group and ARM context where the search service lives - **Algolia Search API** — Hosted search-as-a-service alternative outside the Azure stack ## FAQ ### Why is there no official OpenAPI spec for SearchManagementClient? Microsoft Azure does not publish a unified OpenAPI specification for the Cognitive Search ARM control plane. Jentic generates and maintains this spec so that AI agents and developers can call SearchManagementClient via structured tooling. It is validated against the live Azure Resource Manager API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does SearchManagementClient use? It uses Azure Active Directory OAuth 2.0 via the azure_auth flow. Acquire a bearer token for https://management.azure.com/.default and pass it as Authorization: Bearer. Note that this is the management plane; data plane calls to the SearchIndexClient use api-key headers instead. ### Can I scale a search service after it is created? Yes. PATCH to .../searchServices/{searchServiceName} with new replicaCount or partitionCount. Replicas scale read throughput, partitions scale storage and indexing throughput. Both are bounded by the SKU you provisioned. ### How do I regenerate an admin key without downtime? Each search service has primary and secondary admin keys. Switch your applications to use the secondary key, then POST regenerateAdminKey with keyKind=primary. Once applications confirm they are using the new primary, repeat for the secondary. This rotates both keys with zero downtime. ### What are the rate limits for SearchManagementClient? Calls count against Azure Resource Manager subscription throttling, roughly 12,000 reads and 1,200 writes per hour per subscription. Service creation and scale operations are long-running and complete asynchronously, so the throttle bucket only counts the initial PUT or PATCH call. ### How do I provision a search service through Jentic? Search Jentic for provision azure cognitive search, call client.load on the search service PUT operation to receive its input schema, then call client.execute with subscriptionId, resourceGroupName, searchServiceName, sku, and replica and partition counts. Jentic injects the OAuth token and returns the long-running operation handle. ### Can I limit what my agent is allowed to do with the SearchManagementClient API? Yes. Because you run Jentic One yourself, your own rules decide which SearchManagementClient operations and credentials the agent may use. The subscription, resource group, and search service name sit in the URL path (.../searchServices/{searchServiceName}), so you can pin the agent to a single search service. You also choose the exact operations it may call, so destructive actions like deleting a service or regenerating an admin key stay off-limits unless you explicitly grant them.