OTRouter

Developer documentation

One model catalog for language and video.

Call every OTRouter model with the same Team API key and stable public model ID. Use a familiar language contract or the asynchronous Videos lifecycle while Router keeps usage attributable.

Create API keyView models

Quickstart

Complete these four steps once, then use the same Team API key and model ID with any supported protocol.

Base URL

https://router.omnitools.ai/v1

Use this /v1 URL for SDKs and direct API calls. CC Switch with Claude Desktop is the exception: configure the Router root URL from its integration guide.

Using CC Switch with Claude Desktop

CC Switch requires the Router root URL without /v1, plus Direct mode and the Anthropic Messages format.

Open the CC Switch guide
  1. 01

    Confirm your Team is ready

    Sign in to Console, select the intended Team and confirm it has Credits available for a new request.

  2. 02

    Create an API key

    Create a Team API key, optionally set rolling spend limits and copy the secret while it is visible.

  3. 03

    Choose a model ID

    Open the model catalog and copy the stable public ID, not an upstream provider model name.

  4. 04

    Call and verify

    Send the first request, then use its request ID to verify status, tokens and charge in Console.

Treat the API key as a server-side secret

OTRouter shows a newly created secret once. Store it in a secret manager or environment variable, never commit it, and use separate keys and spend limits when you need independent attribution or deletion.

curl https://router.omnitools.ai/v1/responses \
  -H "Authorization: Bearer $OTRouter_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "model": "claude-fable-5",
  "input": "Write one clear release note.",
  "max_output_tokens": 160,
  "store": false
}'

Choose the interface that fits your application

Models, routing, usage attribution and billing are shared. Only the public request and response contract changes.

Responses

/v1/responses

Stateless text and image input, Codex tools and typed streams.

Read reference

Chat Completions

/v1/chat/completions

OpenAI-compatible text or image messages, function tools, reasoning controls and data streams.

Read reference

Messages

/v1/messages

Anthropic-compatible messages with route-gated Claude Code envelopes, client tools, thinking and named SSE events.

Read reference

Videos

/v1/videos

Asynchronous text and reference-media video generation with one polling contract.

Read reference

Use Console to operate the Router

API activity belongs to the authenticated Team. Console exposes the same identity, usage and billing facts recorded by the Router.

API keys

Create keys, apply rolling spend limits and revoke credentials while retaining usage history.

Manage keys

Requests

Inspect protocol, model, status, error code, metered usage, price and charge for each call.

Inspect requests

Reports

Review Team-wide request counts, metered usage categories and total USD charges calculated from settled requests.

View reports

Automatic routing

Route selection and fallback stay private behind each stable model ID.

Automatic by default

Router filters candidates by the requested protocol and capabilities, then applies configured priority and internal cost.

Bounded fallback

Retryable upstream failures can move to the next eligible route within the request deadline.

Request identity

Every response carries a request ID that links API behavior to the corresponding Console record.

Data boundaries

The public API keeps language generation stateless while recording only the operational and billing facts needed to run the service.

Team-owned activity

The API key determines the Team that owns the request, settled usage and charge.

No body logging by default

Operational request records do not store prompt or model-output bodies. They keep identity, status, usage, price and diagnostic facts.

Stateless language calls

Responses, Chat Completions and Messages never store a conversation. Clients resend complete history for each multi-turn request.

Bounded asynchronous state

Videos keeps only the asynchronous job state addressed by its video ID. Request, usage and billing records follow their documented retention behavior.

Predictable failures

Unsupported fields are rejected instead of being silently ignored. Error messages identify the failing parameter without exposing internal routes.

{
  "error": {
    "message": "The provided OTRouter API key is invalid.",
    "type": "authentication_error",
    "param": null,
    "code": "invalid_api_key"
  }
}

The x-request-id response header is authoritative for Responses, Chat Completions and Videos. Messages also returns request-id and request_id in its error body.

Common questions

The short answers for decisions that affect a first integration.

Which API should I choose?

Use Responses for Codex-style tools, Chat Completions for OpenAI-compatible message clients, Messages for Anthropic-compatible or Claude Code clients, and Videos for asynchronous video generation.

Does OTRouter save conversations?

No. Chat Completions, Responses and Messages are stateless. OTRouter records usage and billing metadata, never prompt or response bodies; send the complete conversation history on each multi-turn request.

Can an application select an upstream provider?

No. The public model ID is the routing input. OTRouter selects and, when eligible, falls back between internal routes without exposing provider controls.

Where can I verify a call and its cost?

Keep the response request ID, then open Requests in Console for per-call status, usage and charge. Use Reports for Team totals and Billing for the Credits ledger.