Microsoft Foundry in Practice

Putting Azure API Management in Front of Foundry

When five teams want Claude, handing each of them the Foundry key stops scaling fast. An API gateway gives every team its own credential, its own limits, and its own line on the usage report — without touching the backend.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Azure API Management (APIM) is Azure's API gateway service: it sits between callers and a backend, applying authentication, throttling, and logging policies on the way through. Putting APIM in front of Claude on Microsoft Foundry is a common enterprise pattern, because Foundry's own access model is deliberately simple — an endpoint, Azure-issued API keys or Entra ID tokens, and subscription-level quota — and a gateway layers per-team control on top of that without any change to the applications' request format. Interestingly, Foundry already routes through Azure API management infrastructure internally: responses carry an apim-request-id header alongside Anthropic's request-id, and support asks for both when tracing an issue.

What the gateway buys you

Credential isolation. The real Foundry credential lives only in the gateway. Developers and applications authenticate to APIM with per-team gateway credentials; APIM injects the Foundry API key (in the api-key or x-api-key header) or, better, attaches an Entra ID bearer token using the gateway's managed identity. Revoking a team's access becomes a gateway operation, not a key rotation that breaks everyone at once.

Per-consumer throttling. Foundry enforces rate limits — requests per minute and uncached input tokens per minute — at the Azure subscription level, shared across all Global Standard deployments of the same model and version. Nothing in Foundry itself stops one enthusiastic team from consuming the entire pool. Gateway rate-limit policies let you divide that shared budget deliberately: production consumers get guaranteed headroom, experiments get a slice that can't grow. Note the unit mismatch, though — APIM natively throttles requests, while half of Foundry's quota is token-based, so a request-count policy is an approximation. Keep per-request max_tokens and prompt sizes bounded if you want request-based limits to track token consumption.

Attribution and audit. With every call passing through one point, you get uniform logging of who called which deployment, latency, and failures. Since Claude billing on Foundry arrives as Claude Consumption Units through Azure Marketplace, gateway logs (paired with the per-model detail in the Foundry portal's Monitoring tab) are the practical raw material for internal chargeback.

Wiring it up

The backend is Foundry's fixed endpoint shape, https://<resource-name>.services.ai.azure.com/anthropic, with the Messages API at /v1/messages. Expose the same path shape on the gateway so client SDKs keep working: the Anthropic Python SDK's AnthropicFoundry client accepts either a resource name or a full base_url (the two are mutually exclusive), so clients simply point base_url — or the ANTHROPIC_FOUNDRY_BASE_URL environment variable — at the gateway instead of at Foundry directly:

import os
from anthropic import AnthropicFoundry

client = AnthropicFoundry(
    api_key=os.environ["TEAM_GATEWAY_KEY"],   # gateway credential
    base_url="https://api.example.com/claude/anthropic/",
)
msg = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=400,
    messages=[{"role": "user", "content": "ping"}],
)

Requests and responses pass through unchanged — the response keeps the standard Claude format including the usage object, which your gateway can also log for token-level accounting.

Rule of thumb: make the gateway transparent. Preserve the /v1/messages path, pass streaming responses through without buffering, and forward the request-id and apim-request-id headers to callers so any team can raise a traceable support issue.

What a gateway does not solve

Three limits survive any amount of gateway engineering. First, the underlying Foundry quota is still shared at the subscription level; a gateway apportions the pool but cannot enlarge it — increases go through Microsoft's quota request process. Second, Foundry does not return Anthropic's anthropic-ratelimit-* headers, so your gateway cannot relay live rate-limit state; plan for 429s with exponential backoff regardless. Third, feature availability is unchanged: capabilities absent from Foundry (the Message Batches API, for example) don't appear because a proxy is in front. Streaming deserves a deliberate test, too — a gateway that buffers responses silently destroys the main UX benefit of streaming.

Where to go next

This article is the Azure instance of a general pattern — see the API gateway pattern for the platform-neutral version. For the pieces referenced here: rate-limit handling, Foundry API keys, and Entra ID auth.

Sources