Azure Integration

Azure provides access to OpenAI's powerful language models through Microsoft's enterprise cloud infrastructure. This guide shows how to create an Azure resource, deploy models, and integrate them with LLM Gateway.

Prerequisites

• An Azure account with an active subscription
• LLM Gateway account or self-hosted instance

Overview

Azure provides enterprise-grade access to OpenAI models with enhanced security, compliance, and regional availability. LLM Gateway integrates seamlessly with Azure deployments.

Create Azure Resource

Add to LLM Gateway

curl -X POST https://api.llmgateway.io/v1/chat/completions \
  -H "Authorization: Bearer YOUR_LLMGATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "azure/gpt-4.1-mini",
    "messages": [
      {
        "role": "user",
        "content": "Hello from Azure!"
      }
    ]
  }'

Available Models

Browse the Azure models page for currently available mappings. Only models deployed in your Azure resource can serve requests. Deployment names must match the Azure mapping's upstream ID; gateway requests still use the canonical model ID.

Azure availability varies by model and resource region, even for Global Standard deployments. If the portal reports an unsupported region, deploy in a supported region and configure that resource's provider key. A catalogue mapping alone does not create a deployment or make Azure available for automatic fallback.

The same key also serves embeddings (/v1/embeddings), text-to-speech (/v1/audio/speech), and realtime speech and transcription sessions (/v1/realtime) for Azure-mapped models. The gateway calls the resource's v1 API (https://<resource>.openai.azure.com/openai/v1) for these endpoints regardless of the key's deployment type. A key with a base URL instead of a resource uses that base URL for every Azure endpoint, including these.

Azure uses the same gateway parameters for speech formats, speed, delivery instructions, realtime voices, audio codecs, turn detection, noise reduction, input transcription, and function calling as OpenAI. Availability still depends on the upstream model: some Azure speech deployments expose fewer voices. Use the provider mapping's supported_voices from GET /v1/models rather than assuming OpenAI's voice list applies.

Speech generation streams audio as it arrives and supports SSE on compatible mappings. Realtime sessions support image input and native MCP tools with authorization and usage accounting. Stored provider prompt references and native WebRTC/SIP remain outside the gateway's supported API for both providers.

Migrate from Azure AI Foundry

The legacy azure-ai-foundry provider uses the Azure Model Inference API. Its replacement is the existing azure provider in AI Foundry mode, which uses Azure's OpenAI-compatible v1 API. See the legacy models page for affected mappings.

1. Confirm that the same deployments are available in your Foundry resource.
2. Add an Azure provider key using that resource's API key and resource name. Select AI Foundry, not the legacy deployment-based Azure OpenAI type. Set the validation model to an existing upstream deployment name; it may differ from the canonical gateway model ID. Do not apply a single-deployment override to a key intended to serve several models.
3. Change explicit request prefixes from azure-ai-foundry/<model-id> to azure/<model-id>, keeping the canonical model ID unchanged. Update provider restrictions and saved routing configurations that name the legacy provider.
4. Test the new key before removing the legacy credential. Scope keys to the models actually deployed in their resource; do not replace an existing Azure credential belonging to a different resource.

Self-hosted configurations must explicitly configure LLM_AZURE_API_KEY and exactly one of LLM_AZURE_RESOURCE or LLM_AZURE_BASE_URL. The legacy LLM_AZURE_AI_FOUNDRY_* variables are not aliases. Existing legacy credentials and provider IDs remain supported until the scheduled cutoff; azure-anthropic is unchanged.

Priority processing

Azure sells a low-latency Priority processing tier, requested per request via the OpenAI-compatible service_tier field:

curl -X POST https://api.llmgateway.io/v1/chat/completions \
  -H "Authorization: Bearer YOUR_LLMGATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "azure/gpt-5.1",
    "service_tier": "priority",
    "messages": [
      {
        "role": "user",
        "content": "Hello from Azure!"
      }
    ]
  }'

Requirements:

• A Global Standard or Data Zone (US) deployment. Regional standard and EU data zone deployments are not supported. Not every priority-capable model is offered on both — some are Global Standard only, so check Microsoft's availability tables for the model you deploy.
• Model version 2025-12-01 or later, on a model that offers the tier — see the provider card on the models page.
• A subscription entitled to priority processing.

Both provider key types work — the v1 (AI Foundry) and the legacy deployment-based surfaces each accept service_tier and report the tier they served.

Azure serves a priority request at standard when the entitlement is missing, during peak load, on ramp-rate limits, and for long-context prompts on some models. It reports the tier it actually served, so a downgraded request is billed at standard rates and used_service_tier comes back null. See service tiers for the full behaviour.

Claude models on Microsoft Foundry

Claude models are served by Microsoft Foundry through Anthropic's Messages API rather than an OpenAI-compatible endpoint, so they use their own azure-anthropic provider in LLM Gateway.

1. In the Foundry portal, deploy the Claude model you want. The deployment name is what you pass as the model at inference time, so keep the default (the model ID) unless you have a reason to rename it.
2. Add an Azure Anthropic provider key in LLM Gateway with your Foundry API key and the resource name from https://<resource-name>.services.ai.azure.com.
3. Call it with the azure-anthropic/<model> model string:

curl -X POST https://api.llmgateway.io/v1/chat/completions \
  -H "Authorization: Bearer YOUR_LLMGATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "azure-anthropic/claude-opus-4-8",
    "messages": [
      {
        "role": "user",
        "content": "Hello from Microsoft Foundry!"
      }
    ]
  }'

If a request returns DeploymentNotFound, the model has not been deployed in that Foundry resource, or the deployment name does not match the model string you sent. Browse the Claude models routed through this provider at llmgateway.io/models.

Troubleshooting

"Deployment not found" error

• Verify you've created a deployment in Azure Studio
• Ensure the deployment name matches the Azure mapping's upstream ID or the key's explicit deployment override
• Check that the deployment is in the same resource as your API key

"Resource not found" error

• Verify the resource name is correct (check your Azure Portal endpoint URL)
• Ensure your API key belongs to the correct Azure resource
• Confirm the resource is in an active state in Azure Portal

Rate limiting

• Azure has Tokens Per Minute (TPM) quotas per deployment
• Monitor usage in Azure Studio under Quotas
• Request quota increases through Azure Portal if needed for high-volume workloads

Region availability

• Not all models are available in all Azure regions
• Check Azure model availability for your region
• Consider creating resources in multiple regions for better availability