canonical: https://jentic.com/apis/azure.com/azure-custom-providers # Microsoft Azure customproviders Jentic publishes the only available OpenAPI specification for Azure Custom Providers, keeping it validated and agent-ready. Custom Providers extend the Azure Resource Manager control plane with first-class custom resource types backed by your own webhook or proxy endpoint. The API exposes 11 operations across 6 paths to register custom resource provider endpoints, define resource types and actions, and associate Azure resources with those custom resource types. Use it to publish custom resources (e.g. an internal application or vendor SaaS object) so they can be created, listed, and tagged through ARM tooling alongside native Azure resources. ## For AI agents Register Azure custom resource providers and associate Azure resources with them through 11 operations on the Microsoft.CustomProviders resource manager surface. ## Scope Does not implement the custom resource logic, host the proxy endpoint, or run custom workflows - use for registering providers and associations on the Microsoft.CustomProviders namespace only. ## Capabilities - Register a custom resource provider with proxy or cache resource types and custom actions - List and update existing custom resource providers within a subscription or resource group - Create associations between an Azure resource and a custom resource type defined by a provider - List all associations under any ARM scope to inventory custom-typed resources - Delete custom resource providers and their associations during clean-up - Enumerate Microsoft.CustomProviders operations available to the caller ## Use cases ### Publish Internal Tools as ARM Resources Expose an internal platform tool (a feature flag service, internal database, or partner SaaS) as a first-class Azure resource type by registering a custom resource provider that proxies to the tool's API. After registration, ops teams can manage the tool through Azure CLI, Bicep, ARM templates, and Portal alongside native resources, with the same RBAC, tags, and audit log behaviour. Example prompt: Register a custom resource provider 'feature-flags-rp' in resource group 'rg-platform' with a proxy resource type 'flags' pointing to https://flags.internal/api/{flagName} ### Custom Tags via Resource Associations Use associations to attach a custom resource type to any Azure resource, effectively giving that resource a typed sidecar object with arbitrary metadata. Compliance teams use this to mark resources with structured custom data (data classification, business unit ownership, lifecycle stage) that goes beyond what Azure tags allow. The associations endpoints support listing across any ARM scope and deletion when resources are decommissioned. Example prompt: Create an association 'classification' under /subscriptions/{id}/resourceGroups/rg-prod with targetResourceId pointing to a custom resource type registered earlier ### Custom Provider Inventory and Cleanup List all custom resource providers in a subscription or resource group to inventory which extensions exist, who deployed them, and whether their endpoints still respond. Pair with the associations list to identify orphaned associations whose target provider is gone. Delete obsolete providers and associations as part of platform clean-up cycles. Example prompt: List all custom resource providers in subscription /subscriptions/{id} and report any whose provisioningState is not 'Succeeded' ### AI Agent Platform Extension An AI agent supporting platform engineering can register, update, and clean up custom resource providers through Jentic. The agent searches by intent ('register custom resource provider'), Jentic returns the CustomResourceProvider_CreateOrUpdate operation with its schema, and the agent executes the call with managed Azure credentials to extend ARM with new resource types on demand. Example prompt: Search Jentic for 'register an Azure custom resource provider', load the CustomResourceProvider_CreateOrUpdate schema, and execute it with the user-supplied resource type and proxy endpoint ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /subscriptions/{subscriptionId}/providers/Microsoft.CustomProviders/resourceProviders | List custom resource providers in a subscription | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CustomProviders/resourceProviders | List custom resource providers in a resource group | | DELETE | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CustomProviders/resourceProviders/{resourceProviderName} | Delete a custom resource provider | | GET | /{scope}/providers/Microsoft.CustomProviders/associations | List associations under any ARM scope | | DELETE | /{scope}/providers/Microsoft.CustomProviders/associations/{associationName} | Delete an association | ## Key resources - **CustomResourceProvider** — Register, list, and delete custom resource providers under a subscription or resource group - **Associations** — Create, list, and delete associations linking Azure resources to custom resource types - **Operations** — Enumerate Microsoft.CustomProviders operations available to the caller ## Why Jentic - **Setup:** Wiring Azure Custom Providers by hand means registering an Azure AD app, handling MSAL token exchange against management.azure.com with the user_impersonation scope, and polling long-running ARM operations for provider and association changes yourself. Through Jentic you install once, import Custom Providers from the API Directory, store the Azure service principal credential once, and your agent calls it. - **Permission scoping:** Custom Providers puts the provider and association names in the URL path (/subscriptions/{id}/resourceGroups/{rg}/providers/Microsoft.CustomProviders/resourceProviders/{resourceProviderName}), so a rule can pin your agent to a specific resource group scope. You choose the operations it may call, so destructive ones like CustomResourceProvider_Delete or Associations_Delete 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 as a scoped ARM bearer token at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'register an Azure custom resource provider' or 'create a resource association', and Jentic returns the matching Custom Providers operation with its input schema so the agent calls the right endpoint without reading the ARM reference docs. ## Related APIs - **Resource Management** — Manage native ARM resources alongside the custom resource types defined by Custom Providers. - **Policy Client** — Apply Azure Policy to custom resource types once they are registered through Custom Providers. - **Authorization Management** — Grant RBAC roles on custom resource providers to control who can manage them. ## FAQ ### Why is there no official OpenAPI spec for customproviders? Microsoft Azure does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call customproviders 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 Custom Providers API use? It uses Azure Active Directory OAuth 2.0 against https://management.azure.com/ with the user_impersonation scope. The caller needs Contributor or a custom role with Microsoft.CustomProviders/* permissions on the resource group. Jentic stores the service principal credentials encrypted and issues bearer tokens at execution time. ### Can I register both proxy and cache resource types? Yes. The CustomResourceProvider create-or-update body accepts a resourceTypes array, where each entry defines a name, mode (Proxy or Cache), routingType, and an endpoint URL that ARM forwards requests to. Cache types persist resource state in ARM, proxy types do not. ### What are the rate limits for the Custom Providers API? Azure Resource Manager applies subscription-level read and write throttling (around 1,200 requests per hour). Calls that fan out to the underlying provider endpoint also depend on that endpoint's own rate handling. ### How do I associate a resource through Jentic? Run pip install jentic and search for 'create an azure custom provider association'. Jentic returns the Associations_CreateOrUpdate operation; load its schema and execute it with the {scope}, associationName, and a body containing targetResourceId pointing to a registered custom resource type. ### Does this API run my custom logic for me? No. Custom Providers route ARM calls to your endpoint - your endpoint implements the logic. This API only registers the provider, defines its resource types, and manages associations. ### Can I limit what my agent is allowed to do with the Custom Providers API? Yes. Because Jentic One is self-hosted, you decide which Custom Providers operations your agent may call, so read-only calls like listing providers and associations can be allowed while destructive ones such as CustomResourceProvider_Delete or Associations_Delete stay out unless you add them. Since the provider and association names live in the ARM URL path, your own rules can pin the agent to a single subscription or resource group scope. The Azure service principal credential is stored encrypted by your instance and injected as a scoped bearer token at execution time, never entering the agent's prompt or logs.