Skip to main content
The gateway is reachable at https://gw.to11.ai/v1. It exposes chat ingress endpoints, model discovery, embeddings, token counting, image generation, audio (transcription + TTS), and file management. Each chat endpoint accepts requests in its native SDK format, normalizes them internally, and responds in the caller’s format.
Send x-to11-authorization and x-to11-project-id on every request (see Authentication). For brevity, most examples on this page show only the upstream provider credential — Authorization: Bearer (or x-api-key for Anthropic-style requests) — and omit the two x-to11-* headers. Drop the provider credential entirely when it is managed in the dashboard.

Endpoints

The model field determines which upstream provider handles the request. In addition to plain model names (e.g. gpt-4o), the model field supports namespace prefixes (separated by ::) for explicit routing:
  • function::name — route to a named function defined in your to11 project’s routing
  • route::name — route to a named route
  • provider::model — route to a specific provider (e.g. anthropic::claude-sonnet-4-6)
Provider-native passthrough routes also exist under /v1/bedrock/*, /v1/vertex/*, and /v1/mistral/* for advanced provider-specific APIs; those forward request bodies to the upstream verbatim and are gated to providers that support them.

Headers

Authentication

Gateway requests use two independent credentials:
  1. Your to11 platform key authenticates the request to to11 and is sent in the x-to11-authorization header. The x-to11-project-id header selects which project’s routing and provider configuration applies.
  2. The upstream provider credential. Either the project’s provider credentials are configured in the dashboard (project → Gateway), in which case you send nothing extra; or you pass your own provider key (BYOK) in the standard Authorization: Bearer <provider-key> header (or x-api-key for Anthropic-style requests). The gateway forwards that key to the upstream provider.
The standard Authorization header carries the upstream provider key, not your to11 key. Put the to11 key in x-to11-authorization. When provider credentials are managed in the dashboard, you can omit Authorization entirely.

SDK detection

The gateway auto-detects the caller’s SDK format from the endpoint. Override with:

Provider hints

Force routing to a specific provider:
Or use a provider::model prefix in the model field:
If both header and prefix are present, they must agree or the request is rejected.

Chat completions

OpenAI format

Response:

Anthropic format

Response:

Cross-format routing

Send an OpenAI-format request to an Anthropic model — the gateway translates the request and returns an OpenAI-format response:
System messages are correctly forwarded: the gateway extracts {"role": "system"} messages and passes them as Anthropic’s top-level system field.

Streaming

Add "stream": true to any request to receive Server-Sent Events:
The gateway streams in the caller’s native SSE format. See Streaming for details on fast-path vs normalized-path behavior.

Structured output

The response_format field is supported for OpenAI models:
Supported types: text, json_object, json_schema. Anthropic models do not support json_object or json_schema — requests with these formats routed to Anthropic return 400 Bad Request.

Tool calls

The tools field is forwarded to the upstream provider. For Anthropic models, tool definitions are automatically translated to the input_schema format:

Models

List all configured models or retrieve a single model. The list is built from your project’s gateway configuration — no upstream provider call is made.

Embeddings

Passthrough proxy to OpenAI-compatible providers. The request is routed by model name. Anthropic models return 400 Bad Request.
Input text is scanned by the security pipeline (PII + blocklist) when security is enabled. Embedding model names must be listed in the provider’s models config array.

Token counting

Passthrough proxy to Anthropic’s /messages/count_tokens endpoint. Only Anthropic models are supported — OpenAI models return 400 Bad Request.
Response: {"input_tokens": 14}

Image generation

Passthrough proxy to OpenAI-compatible providers’ DALL-E endpoint. Anthropic models return 400 Bad Request.
The prompt field is scanned by the security pipeline when enabled. Image model names must be listed in the provider’s models config array.

Audio transcription

Passthrough proxy to OpenAI’s Whisper endpoint. The request must be multipart/form-data containing an audio file. No security scanning is applied (binary audio input).

Audio speech (TTS)

Passthrough proxy to OpenAI’s text-to-speech endpoint. Anthropic models return 400 Bad Request.
The input field is scanned by the security pipeline when enabled.

Files

Passthrough proxy to OpenAI’s file management endpoints. Supports upload (multipart), list, retrieve, download, and delete. Anthropic models return 400 Bad Request. No security scanning is applied.

Response headers

The gateway adds these headers so clients can classify and correlate responses without parsing the body:

Error responses

Errors are returned as a JSON object with a top-level error key, in the caller’s SDK shape:
The stable classification lives in the x-to11-error-code header rather than the body text. See Error handling for the full error-code taxonomy, cross-provider translation, and retry guidance.