What does OpenAI-compatible actually mean?

It means the service accepts the same request format as OpenAI's Chat Completions endpoint — POST /v1/chat/completions with a model and a messages array — and returns the same response shape, including a choices array and a usage token count. Any OpenAI SDK therefore works against it after changing the base URL and API key.

Do I have to rewrite my code to use an OpenAI-compatible API?

No. You change two values, the base URL and the API key. Calls such as client.chat.completions.create stay exactly as written, including streaming and tool calls.

Does OpenAI-compatible mean I get identical results?

No. Compatibility covers the request and response format, not the model behind it. Different models produce different output, have different context windows, and cost different amounts per token.

Will every parameter I send be honoured?

Not necessarily. A provider that does not support a parameter may ignore it silently rather than return an error, so the request succeeds and the setting simply has no effect. Verify that options you depend on actually change the output.

Are model IDs the same across compatible providers?

No. Model IDs are provider-specific, so switching usually means changing the model string even though the rest of the code is unchanged.

Blog

What Is an OpenAI-Compatible API? A Plain Explanation (2026)

Updated 2026-08-16 · ~3 min read

An OpenAI-compatible API is any service that accepts the same request format as OpenAI's Chat Completions endpoint and returns the same response shape. In practice that means you can keep your existing code and SDK, change two values — the base URL and the API key — and start calling a completely different provider's models. Compatibility is about the envelope, not about the model inside it.

What exactly is compatible?

The parts your code touches:

The route — POST /v1/chat/completions, with /v1/models for discovery.
The request body — model, a messages array of {role, content}, and the familiar knobs: temperature, max_tokens, stream, tools.
The response body — a choices array, each with a message, plus a usage block counting prompt and completion tokens.
Streaming — server-sent events with data: lines and a terminating [DONE], when stream: true is set.
Auth — a bearer token in the Authorization header.

Because all five are fixed, the official OpenAI SDKs work unmodified. That is the entire value of the standard: it turned one company's HTTP shape into the lingua franca that gateways, local runtimes and hosting providers all speak.

How do I point my code at one?

Two lines. Python:

from openai import OpenAI

client = OpenAI(
    api_key="sk-...",
    base_url="https://www.superbapi.com/v1",
)

Node:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.SUPERBAPI_KEY,
  baseURL: "https://www.superbapi.com/v1",
});

Everything downstream — client.chat.completions.create(...), streaming, tool calls — stays exactly as written.

What compatibility does not promise

This is where people get caught out. A compatible endpoint guarantees the shape of the exchange, not the contents:

Guaranteed	Not guaranteed
Request and response format	That a given model ID exists
Your SDK keeps working	Identical output for identical input
Streaming event structure	The same context window or token limits
Token counts in `usage`	The same price per token
Bearer authentication	Every optional parameter being honoured

Two consequences are worth planning for. First, parameters can be silently ignored rather than rejected — a provider that does not support a field may accept your request, drop it, and return a perfectly normal-looking answer. Second, model IDs are not portable: switching providers usually means changing the model string, even though nothing else changes.

Why do gateways use this standard?

Because it makes the model a runtime choice instead of an architectural one. A multi-model gateway exposes one compatible endpoint and routes each request to whichever provider owns the model you named — so switching from one vendor's model to another's is a string change, not a rewrite. It also means the ecosystem built around the OpenAI SDK, which is most AI tooling, works against every model the gateway serves without anyone writing an adapter.

How do I check a service is genuinely compatible?

Ask it for its model list and read one back:

curl https://www.superbapi.com/v1/models \
  -H "Authorization: Bearer $SUPERBAPI_KEY"

A compatible service returns {"object":"list","data":[{"id":"...","object":"model",...}]}. If that works and a chat completion round-trips, your SDK will be fine.

Browse the models

SuperbAPI is an independent aggregator and is not affiliated with, endorsed by, or partnered with any model owner. Third-party product names are used nominatively to describe compatibility and routing. Comparisons reflect our understanding at publication and may change.