Skip to main content
This section covers what the API does once your first request works. Every page here describes behaviour you reach through the same endpoint and the same key, so nothing below needs a second integration. Three questions bring people here, and the groups in the sidebar answer one each.

Which model should I name?

Model ids carry their provider, the set of callable models is a live fact rather than a documented list, and models arrive and retire on their providers’ schedules rather than ours.

Models

Id forms, how to discover what your key can call, and how a rate is expressed.

Model capabilities

Which features a given model supports, and how to ask before you rely on one.

Model lifecycle

How a model appears, changes, and goes away, and what your code sees when it does.

What can I put in a request?

These are the request-shaping features. Each is the OpenAI parameter you already know, with a note on what differs when a router rather than a single provider is serving it.

Streaming

Server-sent events, the usage comment before the final line, and mid-stream failure.

Tool calling

Passing tools through, and what a model that cannot call them does instead.

Structured outputs

JSON mode and schema-constrained responses, and which models honour them.

Image inputs

Multi-modal messages, and the refusal a text-only model returns.

Reasoning

Reasoning-model behaviour, the tokens it spends, and how they are billed.

Prompt caching

Where caching happens, who controls it, and what it does to a request’s cost.

Which endpoint do I call?

Chat completions is the one most people start with. Four more serve on the same key, the same model ids and the same balance.

Responses API

OpenAI’s Responses format, and the stored-state fields we refuse because we keep nothing.

Completions and embeddings

The legacy text completion endpoint, and where embeddings stand: not served yet.

Anthropic Messages API

The Messages wire for Anthropic SDKs and harnesses, with either credential header.

Usage lookup

Read one request’s tokens and charge back with the key that made it.

What happens when something goes wrong?

Routing is the part of the product you did not have when you called a provider directly, so it is the part worth reading before an incident rather than during one. Guardrails are the part that stops a key before it becomes an incident.

Routing profiles

How a request reaches a provider, and what you can say about that choice.

Bring your own key

Serving a model on your own provider credential instead of ours.

Guardrails

A spend cap, a data-retention rule and prompt checks, attached per key.

Errors

The error envelope, the closed set of types, and what each one asks you to do.

Try it without writing code

The playground sends real requests on your workspace’s credit, which makes it the fastest way to check whether a model does what a page here says it does.

Coming soon

Images, audio and video are built and closed in production. That page says what each door will take, how it will be charged, and the 404 it answers today.