Skip to main content

Gateway API

Format Translation

An application and a model provider can use different API formats. Verdictan can translate the request to the provider format. It can translate the response to the application format.

For example, an application can send an OpenAI Chat Completions request to a configured Anthropic target. The application reads choices from the response. The gateway translates the message format.

Select the provider's integration guide for setup. This page is the compatibility reference. A supported format does not show compatibility with all endpoints or models from that provider.

Route-native formats​

Each public route has one client format. The gateway compares it with the format of the selected provider target.

Public routeClient format
POST /v1/chat/completionsOpenAI Chat Completions
POST /v1/responsesOpenAI Responses
POST /v1/messagesAnthropic Messages
POST /v1/embeddingsOpenAI embeddings
POST /v1/audio/transcriptionsOpenAI audio
POST /v1/audio/speechOpenAI audio

For a route that is not in this table, the gateway infers the format from the request body.

Implemented mappings​

The provider format values that the parser accepts are openai, anthropic, cohere, huggingface, replicate, watsonx, google-gemini, and aws-bedrock.

The request and response translator implements these pairs, from OpenAI to the listed format and from the listed format to OpenAI:

OpenAI format andRequestBuffered response
anthropicYesYes
cohereYesYes
huggingfaceYesYes
replicateYesYes
watsonxYesYes
google-geminiYesYes
aws-bedrockNoNo

The parser accepts aws-bedrock as a format, but the translator has no OpenAI-to-Bedrock request path. A request that uses that pair fails with unsupported request translation. The enum value does not show Bedrock conversion support.

A pair that has no OpenAI side, such as anthropic to cohere, has no direct mapping.

The gateway translates a buffered response back to the route-native shape for /v1/chat/completions, /v1/messages, and /v1/responses. For /v1/responses, a non-OpenAI provider response first becomes an OpenAI Chat Completions response and then a Responses object.

Streaming translation​

Streaming uses a different stateful translator. It implements these route and provider combinations:

Public routeProvider stream format
/v1/chat/completionsanthropic, cohere
/v1/responsesanthropic, cohere, openai (Chat Completions stream)
/v1/messagesopenai

For other combinations, the gateway forwards the provider SSE frames unchanged. A streaming pair can support fewer features than the same buffered pair.

What a translation does not prove​

A translated JSON body does not show an authenticated connection. A deployment name, project, API version, or authentication exchange can also be necessary.

Use the provider's integration guide to configure those fields. Send a small request through your gateway. Verify these results:

  1. The provider accepts the request.
  2. The response has the shape that your client can read.
  3. The necessary feature, for example, tool calls or streaming, operates correctly.

A text response without an error does not show support for tool calls, images, or structured output through the same translation.

Feature preservation​

Translation preserves only the fields that have an implemented mapping. Text messages, system instructions, token limits, sampling settings, tools, tool results, finish reasons, and usage data map differently for each pair. A mapping can drop an unknown or provider-only field.

When the client supports the native format of a route, use that route without translation. Before you use a translated pair, verify each necessary feature with the selected target. Include tools, multimodal blocks, structured output, streaming, and usage accounting as applicable.

Next steps​