OpenAI API — AI Glossary

Reference details

Related terms

• Anthropic API
• OpenAI-Compatible API
• Chat Completion

How it works

1. A request is a POST carrying a bearer token in the authorisation header, with the model named as a string in the body rather than encoded in the path.
2. That string is an opaque identifier the server resolves to its own weights, which is why a floating alias can change what it points at without any client change — and why production pins a dated snapshot.
3. The response carries the completion inside a choices array alongside a usage object with input and output token counts, so billing is reconcilable from the response rather than estimated.
4. A finish reason distinguishes a natural stop from hitting the token limit from a tool call, and it is the only way to tell a complete answer from a truncated one — the text itself gives no signal.
5. Streaming returns server-sent events carrying incremental deltas, with usage typically arriving only at the end, so a streamed call cannot report its cost until it completes.
6. Only the chat route follows this shape: embeddings return vectors against a flat input array, and audio takes multipart form data rather than JSON — so the compatibility standard other providers implement covers one endpoint of a family, not the family.

Example: “OpenAI-compatible” describes the request, not the behaviour

Dozens of providers accept the same request shape — a messages array, a model string, temperature, tools — which is why swapping a base URL appears to work. What varies underneath: which sampling parameters are honoured versus silently ignored, whether tool calling is supported and in which dialect, whether structured output guarantees schema conformance or merely requests it, how streaming chunks are framed, and what the error codes mean. The shape is portable; the behaviour is not. Treat a provider swap as a change requiring the same evaluation run as a model swap, because it is one.

Commonly confused with

The chat completions shape is the compatibility standard; it is not the only interface OpenAI offers, and newer stateful endpoints deliberately differ by keeping conversation state server-side. Compatibility claims also cover only the endpoint surface — rate limits, retention policies, data-training terms and regional routing are per-provider and are usually the reasons the choice matters.

When to use it

Reach for it when:

• As the default integration target, since it maximises provider portability
• Gateways and routers, which normalise other providers into this shape
• Prototyping against a hosted model before deciding on self-hosting

Reach for something else when:

• Assuming a compatible endpoint behaves identically — verify parameters and tool support
• Where you need provider-specific features that the shared shape cannot express
• Hard-coding a floating model alias in production; pin the version

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to OpenAI API — AI Glossary.

• Browse models
• Review providers
• Inspect benchmarks
• Explore workflows
• Learn AI concepts
• Read decision guides
• Review trust and methodology
• Start a decision path