PAI

Developer documentation

One model catalog. Three familiar APIs.

Call every PAI model with the same Team API key and stable model ID. Router keeps usage attributable and returns the response shape your application already understands.

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

OpenAI-compatible clients usually use this /v1 URL. Direct requests append /responses, /chat/completions or /messages as shown below.

  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

PAI 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 revocation.

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

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

Text and image input, Codex tools, optional stored Sessions 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, Claude Code beta envelopes, images, tools and named SSE events.

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 or delete credentials without changing application code.

Manage keys

Requests

Inspect protocol, model, status, streaming mode, error code, token usage, price and charge for each call.

Inspect requests

Usage

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

Review usage

Sessions

Inspect and delete the response trees created only when the Responses API is called with store: true.

View sessions

Automatic routing

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

Automatic by default

Router prefers native protocol support and ranks compatible candidates by recent availability 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 and state boundaries

The public API makes storage and ownership explicit so applications can choose when state exists.

Team-owned activity

The API key determines the Team that owns the request, reserved Credits, 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.

Explicit Responses state

All protocols are stateless by default. Only Responses with store: true create a Team-owned Session that can be continued, inspected or deleted.

Thirty-day stored Sessions

Stored Response state expires after 30 days of inactivity. Request, usage and billing records follow their own 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 PAI API key is invalid.",
    "type": "authentication_error",
    "param": null,
    "code": "invalid_api_key"
  }
}

The x-request-id response header is authoritative for Responses and Chat Completions. 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 or optional PAI-managed continuation, Chat Completions for OpenAI-compatible message clients, and Messages for Anthropic-compatible or Claude Code clients.

Does PAI save every conversation?

No. Chat Completions and Messages are stateless, and Responses defaults to store: false. Send store: true only when you want a PAI-owned Session and continuation with previous_response_id.

Can an application select an upstream provider?

No. The public model ID is the routing input. PAI 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 Usage for Team totals and Billing for the Credits ledger.