Skip to main content
The chat endpoint is drop-in compatible with the OpenAI SDK. Point any OpenAI client at our base URL and your existing code keeps working — we route the model to the best healthy provider behind the scenes.

Quickstart

Request body

The request body follows the OpenAI chat completions schema. The most common fields:
string
required
Model ID without any provider prefix (e.g. gpt-4o, claude-opus-4-6, llama-4-405b). The router resolves it to the best provider.
array
required
Conversation history. Each message has role (system, user, assistant, or tool) and content (string or content parts for multimodal models).
boolean
default:"false"
When true, the response is a Server-Sent Events stream of incremental deltas — same wire format as OpenAI.
number
Sampling temperature. Range and behavior depend on the underlying model.
integer
Maximum tokens to generate. Capped per-model where the provider enforces a limit.
array
Tool / function definitions. Forwarded verbatim to providers that support tool calling.
object
Set { "type": "json_object" } for JSON-mode, or { "type": "json_schema", "json_schema": {...} } for structured outputs (where supported).
Any other OpenAI-supported parameter (top_p, presence_penalty, frequency_penalty, seed, logprobs, stop, user, …) is forwarded to the provider when supported.

Response

The response is an OpenAI chat.completion object:

Streaming

Set stream: true to receive a text/event-stream of chat.completion.chunk events:
The stream terminates with data: [DONE], exactly like OpenAI. Failover is handled before the first byte goes out — once streaming starts, the connection sticks with the chosen provider.

Multimodal input

Models that accept images, audio, or files use the standard OpenAI content-parts shape:

Errors

Failures use the shared error envelope. Provider-classified failures map to standard HTTP statuses: