> Raw Markdown twin (generated at build time from the source Markdown). Rendered page: https://docs.gatellm.io/en/reference/protocol-matrix · Doc index: https://docs.gatellm.io/en/llms.txt


# 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](/en/reference/realtime.md)) |
| `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](/en/reference/endpoints.md#aws-bedrock-passthrough).

**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](/en/reference/endpoints.md) for the full endpoint list; [Client integration and gateway differences](/en/reference/clients-and-gateway-diffs.md) for SDK connection; [Upstream and model fields](/en/reference/upstreams-models-fields.md) for model protocol configuration.