Add Azure AI Foundry as a first-class v2 provider
Motivation
Azure OpenAI is currently usable via instructor.from_openai(AzureOpenAI(...)), but there is no dedicated from_azure() factory, no from_provider("azure/...") routing, and no AZURE_OPENAI_* environment variable auto-detection — all of which exist for other OpenAI-compatible providers like groq, perplexity, fireworks, cerebras, and xai.
Beyond ergonomics, Azure AI Foundry now hosts non-OpenAI models (Mistral, Llama, Phi, etc.) through a single endpoint. A dedicated provider would add routing value that from_openai(AzureOpenAI(...)) cannot provide — the same justification that motivated first-class providers for other OpenAI-compatible platforms.
Proposed scope
Mirror the v2 provider pattern (following PR #2306 MiniMax as the template):
instructor/v2/core/mode.py—AZURE_TOOLS,AZURE_JSONinModeenuminstructor/v2/core/providers.py—Provider.AZURE, URL detectioninstructor/v2/core/provider_specs.py—PROVIDER_SPECSentryinstructor/v2/providers/azure/handlers.py—AzureToolsHandler(extendsOpenAIToolsHandler)instructor/v2/providers/azure/client.py—from_azure()factoryinstructor/v2/auto_client.py—_build_azure()readingAZURE_OPENAI_*envinstructor/providers/azure/client.py— legacy compat shiminstructor/__init__.py— lazy import + exportdocs/integrations/azure.md,tests/llm/test_azure/(auto-skip without key)mkdocs.yml,CHANGELOG.md,pyproject.toml(optionalazure-identitydep for Entra ID)
Most files are 1-10 line shims/registry entries. Real substance = handler + client + tests + docs.
Context
- #1692 (Entra ID support) was completed — Azure IS maintained, not rejected
- #2039 (URL detection centralization) by @jxnl was merged — the plumbing a new provider needs is in place
NEW_PROVIDER_AGENT_INSTRUCTIONS.mdis outdated (pre-v2); PR #2306 is the authoritative v2 template
Ask
Would a PR for this be welcome? Happy to mirror the MiniMax v2 pattern. If there's a preference for scope (e.g., Azure OpenAI only vs. full Foundry routing), I can adjust.
Source: 567-labs/instructor