Skip to content

[BUG] Microsoft.CognitiveServices: undocumented required modelProviderData property for Anthropic Claude deployments #43610

Description

API Spec link

specification/cognitiveservices/resource-manager/Microsoft.CognitiveServices/stable/2025-09-01/cognitiveservices.json

(also missing from preview/2025-10-01-preview/cognitiveservices.json and earlier preview spec families)

API Spec version

2025-09-01 (stable) — and 2025-10-01-preview

Describe the bug

The Microsoft.CognitiveServices/accounts/deployments resource has an undocumented required input property — modelProviderData — that the Cognitive Services RP requires when deploying any Anthropic / Claude model on a Foundry (Kind=AIServices) account, but the property does not appear anywhere in the OpenAPI spec.

I verified this on the published stable spec — grepping the entire 2025-09-01/cognitiveservices.json (10052 lines) for modelProviderData, AnthropicOrganization, or allowProjectManagement returns zero matches.

Concretely, the RP requires:

"properties": {
  "model": { "format": "Anthropic", "name": "claude-sonnet-4-6", "version": "..." },
  "modelProviderData": {
    "organizationName": "<legal entity name>",
    "countryCode": "<ISO-2>",
    "industry": "<lowercase enum: technology|finance|healthcare|...>"
  }
}

If modelProviderData is omitted, the deployment fails after several minutes of LRO polling with:

Status: "Failed"
Code:   "AnthropicOrganizationCreationException" (or "AnthropicOrganizationCreationFailed")
Message:"Internal Server Error."

Expected behavior

modelProviderData should be a documented property of the DeploymentProperties (or Deployment request body) model in the spec, with:

  1. The three sub-fields (organizationName, countryCode, industry) defined with the right types and required/optional flags.
  2. A conditional-required marker ("modelProviderData" is required when "model.format" == "Anthropic") — either via x-ms-discriminator-value on a DeploymentProperties polymorphism, an OpenAPI oneOf, or at minimum a description note.
  3. The industry field documented as an enum with its accepted lowercase values, matching what the Foundry portal dropdown sends.
  4. The same property surfaced on Get responses, not just PUT requests, so consumers can read back what they sent.

Once it's in the spec, the downstream SDKs (hashicorp/go-azure-sdkterraform-provider-azurerm, azure-sdk-for-net, etc.) will pick it up on their next regen.

Actual behavior

modelProviderData is completely absent from the spec. As a result:

  1. azurerm_cognitive_deployment cannot deploy Claude models at all. This is the explicit blocker called out by the terraform-provider-azurerm collaborator on hashicorp/terraform-provider-azurerm#31140 (comment of Feb 8): "Since the modelProviderData object is currently undocumented, we're unable to rely on it for Terraform (TF) generation."
  2. Users are forced to use azapi_resource with schema_validation_enabled = false and a hand-written body block, losing schema validation and plan-time type checking.
  3. The error path is opaque — AnthropicOrganizationCreationException / Internal Server Error gives no hint that a property is missing. The fact that the workaround exists was discovered by scraping what the Foundry portal sends (per the terraform-provider-azurerm#31140 thread comment by @rlaveycal on Jan 16).
  4. Same problem will eventually block every other SDK that depends on the OpenAPI generator (azure-sdk-for-net, azure-sdk-for-python, azure-sdk-for-js, Bicep types).

Bicep already partially "knows" about it — the Bicep types repo emits BCP037 Warning: The property "modelProviderData" is not allowed on objects of type "DeploymentProperties" for the exact same template, but the deployment succeeds at runtime because the ARM RP accepts the property.

Reproduction Steps

  1. Create an AIServices Foundry account in eastus2 or swedencentral (any subscription with Anthropic-on-Foundry entitlement).
  2. PUT a Claude deployment using only the documented properties — no modelProviderData:
    az rest --method put \
      --url "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.CognitiveServices/accounts/<account>/deployments/claude-sonnet-4-6?api-version=2025-09-01" \
      --body '{
        "sku": { "name": "GlobalStandard", "capacity": 25 },
        "properties": {
          "model": { "format": "Anthropic", "name": "claude-sonnet-4-6", "version": "20250929" }
        }
      }'
  3. LRO polls for ~4–8 minutes, then fails with:
    "status": "Failed",
    "error": {
      "code": "AnthropicOrganizationCreationException",
      "message": "Internal Server Error."
    }
    
  4. Repeat with modelProviderData populated (using the undocumented shape above) — succeeds.

Environment

  • API surface: Microsoft.CognitiveServices stable 2025-09-01 and preview 2025-10-01-preview.
  • Affected SDKs (downstream consumers):
  • Repro region: eastus2. Same behavior on swedencentral per multiple commenters on the linked issue.

Related

  • hashicorp/terraform-provider-azurerm#31140"Support for Anthropic Model Deployment (fix AnthropicOrganizationCreationException)" — collaborator (@promisinganuj) explicitly identifies this spec gap as the reason the provider can't yet support Claude natively. Filing this issue at their request.
  • hashicorp/terraform-provider-azurerm#32283 — closed as duplicate of the above.
  • Real-world starter kit working around this with azapi_resource: Azure-Samples/claude — see infra-terraform/infra/main.tf.

Metadata

Metadata

Assignees

No one assigned

    Labels

    FoundrybugThis issue requires a change to an existing behavior in the product in order to be resolved.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions