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.

For route-level provider support, see Provider Compatibility.

Choose an Adapter

How you select an adapter depends on how you manage the gateway:

• For an AISIX Cloud catalog provider, select the provider. The control plane derives the adapter, and the AISIX Cloud Admin API rejects an explicit adapter field.
• For a bring-your-own endpoint in AISIX Cloud, set provider to byo and select the adapter explicitly.
• For the open-source AISIX gateway, set both provider and adapter in resources.yaml. The provider is an open string, so you can use a catalog ID or a descriptive name for a private endpoint.

In every case, the provider identifies the upstream vendor or endpoint, while the adapter identifies the protocol family AISIX uses to communicate with it. Adapter values form a closed set because AISIX can only encode implemented protocols.

For example, this AISIX Cloud provider key connects a private OpenAI-compatible endpoint through the OpenAI adapter:

{
  "provider": "byo",
  "adapter": "openai",
  "api_base": "https://llm.private.example/v1"
}

AISIX then uses the OpenAI-compatible protocol for upstream requests to the configured api_base.

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. AISIX Cloud stores the reference in provider_key_id. For the open-source AISIX gateway, resources.yaml uses provider_key with the provider key's display_name. 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:

1. Check whether the provider value has provider-specific request handling.
2. 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.

Catalog and Custom Providers

In AISIX Cloud, users select a catalog provider through the dashboard or AISIX Cloud Admin API. The control plane maps that provider to an adapter family, supplies a default base URL when the catalog defines one, and delivers the provider key configuration to AISIX gateways.

For the open-source AISIX gateway, set provider, adapter, api_base, and the upstream credential (api_key, or its secret alias) directly on each provider key in the declarative resources file.

Runtime behavior depends on the model alias, provider key, provider value, adapter, and connection settings.