What is an OpenAI-compatible API?
An OpenAI-compatible API is a service that accepts requests in the format OpenAI's API defines — most often POST /v1/chat/completions with a messages array — and returns responses in the same shape. Code already written against an OpenAI SDK can call it by changing two values: the base URL and the API key.
Why the convention exists
OpenAI published a request format, a large number of applications were written against it, and the ecosystem of SDKs, frameworks and tools grew up around that shape. Any service that wanted those applications as customers had a choice: persuade every one of them to rewrite an integration, or accept the format they already send. Most chose the second. That is the whole mechanism — it is adoption, not standardisation.
The practical consequence is that the request shape has become the interchange format for the category. It is why switching model providers can be a configuration change, and why a gateway can put five providers behind one endpoint without asking your application to know which one answered.
What it guarantees, and what it does not
The two-line migration, and its honest caveat
Pointing an existing OpenAI client at a compatible endpoint means changing the base URL and the key. In most codebases that really is all, and it is reasonable to plan for it.
The caveat is that “most” is doing work in that sentence. The divergences cluster in streaming, tool calling and structured output, and they surface as subtly wrong behaviour rather than as errors — a tool call that arrives in a slightly different shape, a schema that is suggested rather than enforced. Run your own test suite against the new endpoint before you route production traffic to it. Any vendor telling you that step is unnecessary, including us, is overselling.
Common questions
No, and this is the most common misreading. Compatibility describes the request and response format, not the model behind it. An OpenAI-compatible endpoint may route to Anthropic, Google, Mistral, or a model running on your own hardware. The wire format is what is shared; the intelligence answering is a separate question.
In the typical case, two values: the base URL your client points at, and the API key it sends. Everything else — the messages array, the streaming flag, the tool definitions, the response parsing — stays as written. That is the whole point of the compatibility claim, and it is why migration between compatible services is usually a configuration change rather than a project.
It does not guarantee that every parameter survives. Provider-specific features — extended thinking budgets, cache control headers, safety settings, logprobs, specific tool-calling dialects — have no universal equivalent, so a compatible endpoint may ignore them, approximate them, or reject them. It also says nothing about rate limits, latency, retention, or where the request is processed.
Not a formal one. It is a de facto convention: enough services adopted OpenAI's request shape that it became the interchange format for the category, in the way S3's API became the convention for object storage. There is no standards body and no conformance suite, which is why compatibility is a claim each vendor makes rather than a certification anyone holds.
Point your existing client at it and run your own test suite — that is both the fastest check and the only one that covers the parameters you actually send. Pay particular attention to streaming, tool or function calling, and structured output, because those are where compatible implementations most often diverge.