Protocol interop matrix

The gateway supports translation across 12 protocols: the client protocol and the upstream protocol can differ, and the gateway translates requests and responses bidirectionally.

Protocol list

Protocol	Description
openai	OpenAI Chat Completions
openai_response	OpenAI Responses API
openai_images	OpenAI Images
openai_embeddings	OpenAI Embeddings
openai_audio	OpenAI Audio (ASR/TTS)
openai_rerank	OpenAI-compatible Rerank
anthropic	Anthropic Messages
google	Gemini Generative Language
aws_converse	AWS Bedrock Converse
aws_invoke	AWS Bedrock InvokeModel
dashscope	Alibaba DashScope
openai_realtime	OpenAI Realtime (WebSocket sessions, see Realtime sessions)
dashscope_realtime	DashScope Realtime (WebSocket sessions)
passthrough	Passthrough, no translation

openai_realtime / dashscope_realtime are session-scoped WebSocket protocols that go through the separate /v1/realtime bridge path and do not participate in the HTTP interop matrix above (the matrix entries are all "one-question-one-answer" HTTP protocols).

Interop matrix (bidirectional)

Each pair below is bidirectionally translated (one adapter handles both request → and response ←):

Client protocol	Inter-translatable upstream protocols
openai	anthropic, aws_invoke, google, aws_converse, openai_response, dashscope
anthropic	openai (via chat), aws_invoke, google, aws_converse, openai_response, dashscope
openai_response	openai (via chat), aws_converse, google, dashscope
google	openai, anthropic, openai_response, dashscope, openai_images
openai_embeddings	dashscope
openai_rerank	dashscope
openai_audio	dashscope
openai_images	google (inter-translates only with Google)
aws_converse	openai, anthropic, openai_response
aws_invoke	openai, anthropic
dashscope	openai, anthropic, openai_response, google, openai_embeddings, openai_rerank, openai_audio
passthrough	any (no translation, forwarded as-is)

Combinations where the client protocol equals the upstream protocol take identity (request body forwarded as-is); among them Anthropic→Anthropic is a same-protocol non-passthrough translator (it strips the gateway-encoded thinking signature, keeping cross-instance round-trips compatible).

Passthrough entries

• The passthrough protocol: forwarded directly, no protocol conversion.
• /v3/{model}/{*rest}: identity passthrough entry. When the client protocol == the model's configured target protocol, the request body is forwarded as-is to the upstream.
• DashScope clients have two routes:
  • /v1/services/{*rest}: passthrough, request body sent to DashScope as-is.
  • /v1/chat/completions: translation mode, OpenAI format translated into DashScope format.

Known translation limits

Cross-protocol translation is not lossless; known boundaries:

• Images: openai_images only inter-translates with google (via generateContent's inline image output); other upstreams need native OpenAI image-interface compatibility.
• Embeddings: openai_embeddings is a one-way API (no conversation turns); cross-protocol translation is limited to dashscope; most embedding providers (OpenAI / Azure / Voyage, etc.) offer OpenAI-compatible endpoints directly, so connect via the openai protocol.
• Audio: openai_audio and dashscope multimodal inter-translate transcription / translation (multipart audio ↔ multimodal JSON); but text-to-speech (TTS) has no counterpart in DashScope and returns unsupported_feature.
• General fields: request fields with no counterpart concept in the target protocol are downgraded or dropped during translation. If a field must reach the upstream, first confirm the target protocol has a corresponding field, or switch to passthrough (see above).

When there's no translator

A request's "client protocol → upstream protocol" combination has no translator → returns 400 (unsupported_feature).

How to use this matrix

1. Determine your client's protocol (e.g. OpenAI SDK → openai).
2. Determine the upstream protocol (e.g. Claude → anthropic).
3. Check whether the openai row above contains anthropic — if so, inter-translation is supported, the client doesn't change protocol, and the gateway translates automatically.
4. If not, either change the client protocol or change the upstream protocol to a supported one.

FAQ

Q: The client gets 400 unsupported_feature? That "client protocol → upstream protocol" combination has no translator. Check this matrix and change the client or upstream protocol.

Q: Is Anthropic → Anthropic identity? It's a same-protocol non-passthrough translator (strips the gateway-encoded thinking signature, keeping cross-instance round-trips compatible). Other combinations where the client protocol == the upstream protocol take identity (request body forwarded as-is).

Q: I don't see an AWS Bedrock client protocol in the matrix? AWS Bedrock is an upstream-side protocol, not a client protocol. Clients use OpenAI / Anthropic / Gemini protocol endpoints to access Bedrock models, and the gateway does protocol translation. See Endpoints · auth · protocol interop.

Q: How do I bypass translation? Use the /v3/{model}/{*rest} passthrough entry, where the request body is forwarded as-is when the client protocol == the target protocol. Or set the upstream protocol to passthrough.

Next: Endpoints · auth · protocol interop for the full endpoint list; Client integration and gateway differences for SDK connection; Upstream and model fields for model protocol configuration.