Adapter Protocol Families
An adapter is the upstream protocol family AISIX uses after a model alias resolves to a provider key. It controls upstream authentication, request encoding, and provider-specific request handling.
This document provides a reference for adapter values, provider-key configuration, request handling, and endpoint compatibility.
For route-level provider support, see Provider Compatibility.
Usage
Set the adapter on the provider key. Choose the adapter by upstream API format; the provider value and adapter value are configured independently.
The provider value identifies the upstream vendor or endpoint. It is an open string, such as openai, anthropic, deepseek, amazon-bedrock, google-vertex, azure, or a private endpoint name.
The adapter value identifies the protocol family AISIX knows how to encode. It is a closed set of supported values. Set it on provider keys.
A provider key can keep a custom provider value while selecting a shared adapter family. For example, a private OpenAI-compatible endpoint can use its own provider value and the OpenAI adapter:
{
"provider": "private-chat",
"adapter": "openai",
"api_base": "https://llm.private.example/v1"
}
In this example, AISIX treats private-chat as the provider value and uses the OpenAI-compatible adapter for upstream requests.
Adapter Values
| Upstream API format | adapter | Examples |
|---|---|---|
| OpenAI-compatible APIs | openai | OpenAI, DeepSeek, Groq, Mistral, Together.ai, Fireworks, Perplexity, vLLM, SGLang, Ollama, private OpenAI-compatible endpoints |
| Anthropic Messages | anthropic | Anthropic native Messages API |
| AWS Bedrock Runtime | bedrock | Anthropic Claude on Bedrock, Bedrock Converse publishers |
| Google Vertex AI publisher routes | vertex | Gemini and supported Vertex AI publisher routes |
| Azure OpenAI Service | azure-openai | Azure OpenAI deployments with API-key or Entra ID authentication |
Adapter Behavior
adapter | Behavior |
|---|---|
openai | Uses OpenAI-compatible request and response formats. This adapter covers OpenAI, public OpenAI-compatible vendors, and private OpenAI-compatible endpoints. |
anthropic | Uses Anthropic Messages API requests. Upstream authentication uses x-api-key and anthropic-version. |
bedrock | Uses AWS Bedrock Runtime. AISIX signs outbound requests with AWS SigV4. Anthropic Claude models use Bedrock invoke requests, and other supported publishers use Bedrock Converse. |
vertex | Uses Google Vertex AI publisher routes. AISIX authenticates with a GCP OAuth2 Bearer token and calls publisher-specific Vertex endpoints. |
azure-openai | Uses Azure OpenAI Service deployment routes. AISIX builds Azure URLs from the provider key's resource host and the model's upstream deployment name. |
Request Handling
A direct model references a provider key through provider_key_id. The provider key supplies the provider value and adapter. AISIX uses those fields with the model's upstream model ID to build the provider request.
AISIX selects upstream request handling in two steps:
- Check whether the provider value has provider-specific request handling.
- If it does not, use the adapter family.
If neither path is available, the request fails before reaching the upstream provider.
The model's display_name is the caller-facing model alias. The model's model_name is the upstream model ID. For normalized chat responses, the response model field echoes the caller-facing alias.
Adapters describe the upstream protocol family. They do not guarantee that every proxy endpoint supports every provider.
Cloud Catalog and Self-Hosted Providers
In AISIX Cloud, the control plane maps catalog providers to adapter families and delivers provider key configuration to managed gateways. Cloud users select the provider in the managed workflow; the adapter and base URL are populated by the control plane.
In self-hosted deployments, you set provider, adapter, api_base, and secret directly on each provider key.
Runtime behavior depends on the model alias, provider key, provider value, adapter, and connection settings.