Azure Functions is Microsoft's serverless compute service: you deploy a function, Azure runs it on demand, and you pay per execution. Because Claude on Microsoft Foundry is just an HTTPS endpoint with a standard Python SDK, calling it from a function is straightforward — the decisions that matter are how the function authenticates, where its configuration lives, and how it behaves when a long model response meets a serverless time limit.
Dependencies and client setup
The Foundry client ships in the standard anthropic Python package (pip install -U "anthropic", Python 3.8+), so your function app's requirements.txt needs only that one entry. The client class is AnthropicFoundry, and it reads its configuration from environment variables automatically: ANTHROPIC_FOUNDRY_API_KEY, ANTHROPIC_FOUNDRY_RESOURCE, and ANTHROPIC_FOUNDRY_BASE_URL. In Azure Functions, environment variables come from application settings, so the deployment story is: set two app settings (resource name and key), reference the key from your secret store rather than pasting it, and the code stays credential-free.
import os
import azure.functions as func
from anthropic import AnthropicFoundry
client = AnthropicFoundry() # reads ANTHROPIC_FOUNDRY_* env vars
def main(req: func.HttpRequest) -> func.HttpResponse:
msg = client.messages.create(
model="claude-haiku-4-5", # your deployment name
max_tokens=512,
messages=[{"role": "user", "content": req.get_body().decode()}],
)
return func.HttpResponse(msg.content[0].text)
Create the client once at module level, not inside the handler — function hosts reuse the process across invocations, and reusing the client reuses its HTTP connections. Note that the model value is your Foundry deployment name, which defaults to the model ID but may have been customized when the deployment was created.
Prefer managed identity over keys
Foundry supports two authentication methods: Azure-issued API keys and Microsoft Entra ID tokens. For a function app, Entra ID is the better default because the platform can issue the identity itself — enable a managed identity on the function app, grant it a role such as Cognitive Services User on the Foundry resource, and no key ever exists to rotate or leak. Microsoft's samples use DefaultAzureCredential with a bearer-token provider:
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from anthropic import AnthropicFoundry
token_provider = get_bearer_token_provider(
DefaultAzureCredential(),
"https://ai.cognitiveservices.com/.default",
)
client = AnthropicFoundry(
azure_ad_token_provider=token_provider,
base_url="https://YOUR-RESOURCE.services.ai.azure.com/anthropic/",
)
DefaultAzureCredential automatically picks up the function app's managed identity in Azure and your developer login locally, so the same code runs in both places. If calls return 403, the usual cause is a missing role assignment (Cognitive Services User, or Foundry User per Anthropic's docs). One detail worth knowing: Microsoft's documentation uses the token scope https://ai.cognitiveservices.com/.default while Anthropic's uses https://ai.azure.com/.default — both are documented; if one fails in your tenant, try the other.
Timeouts, retries, and rate limits
Two serverless realities collide with large language models. First, execution time: a long generation from a capable model can take longer than a default serverless timeout, so either cap max_tokens to what the use case needs, raise the function timeout, or move long-running work to a queue-triggered function rather than an HTTP-triggered one. Streaming is supported on Foundry and helps HTTP scenarios where a client is waiting.
Second, rate limits: Foundry enforces requests-per-minute and input-tokens-per-minute limits at the subscription level, and — unlike the first-party Claude API — it does not return anthropic-ratelimit-* response headers. A burst of queue messages fanning out across function instances can hit those limits invisibly. Handle 429 responses with exponential backoff (the SDK retries transient errors, but tune it deliberately for batch-style triggers), and watch utilization through Azure monitoring rather than expecting per-response headers.
When something does go wrong, Foundry responses carry both request-id and apim-request-id headers — log both, since support uses them to trace a request across Anthropic and Azure systems.
Where to go next
See Entra ID authentication for Foundry and rate-limit handling on Foundry for deeper treatments, or the Foundry Python SDK guide for client options beyond the basics.