Skip to main content
Model Gateway is a proxy between your code and your model providers. It accepts a request in the OpenAI or Anthropic format, finds the model you named, sends the request to that model’s provider, and returns the reply in the format you called with.

​
Request lifecycle

Every refusal in steps 1 to 4 happens before the gateway reads a provider credential or calls the provider.

​
Providers and model names

A provider is a connection an organization admin added, such as your OpenAI organization or one AWS Bedrock region. A model is one entry served through that connection. You call a model by its qualified name:
The provider part is the provider’s name, a lowercase slug of its display name such as openai, or openai-2 for a second OpenAI connection. The same upstream model behind two providers therefore has two names, and you choose which connection serves the call. A bare upstream id such as the vendor’s model name alone resolves nothing. Copy the exact id from the catalog:
Each entry has an id, a modality, and is_routable. The list holds only models whose provider is on and that you can call. Add ?modality=embedding to list one modality, or ?is_provider_disabled_included=true to also list models behind a switched-off provider, each with is_routable: false. To check one name without making a call, use GET /openai/v1/models/<provider>/<model>.

​
Which workspace a name resolves in

The gateway looks for the name in your workspace first, then in the organization’s default workspace, where new providers are added. Your workspace comes from the X-Atlan-Workspace-Id header when you send one, otherwise from your credential. The header only chooses where to look: a workspace you can’t read adds nothing.

​
Modalities

Each model has one modality, and only the matching endpoint serves it. Calling a model on the wrong endpoint returns 400 before anything reaches the provider. Beyond modality, each model carries a record of what it can take: input types, tools, streaming, structured output, and context and output ceilings. A request that needs more than the record allows is refused with 400 naming what is missing, such as deployment does not support image input.

​
Translation between dialects

You can call any chat model from either dialect. The gateway calls the provider’s own API for your dialect when the provider has one, and translates your request onto another API the provider serves when it doesn’t. For example, an Anthropic SDK call to a model on Bedrock goes out on Bedrock’s API, and the reply comes back in Anthropic’s format. Each request field is handled by what it means: The model’s family also shapes the request. The gateway fills a default the provider requires, such as max_tokens of 4096 on the Messages API, and drops a field the model forbids when it is sent at its default value. A value the model can’t accept is refused with 400 model_request_unsupported, naming the field. Two response headers on chat replies tell you what happened: Tool definitions, tool calls, and tool results cross dialects with their call IDs intact. Your application runs the tools; the gateway does not.

​
What the gateway keeps

The one exception to “not kept” is the Cache identical responses. It is off by default. When an admin turns it on for a model, the gateway keeps that model’s replies for the time set, keyed by a digest of the request.