OpenAI-compatible API: what it is and how to connect
The term without marketing: what exactly has to match for a client to work unchanged, and what the format does not decide.
Definition
An OpenAI-compatible API is a service that accepts requests in the same shape OpenAI accepts and answers in the same format. Compatibility means concrete things: the /v1/chat/completions path, Authorization: Bearer auth, a body with model and messages, a response with a choices array and a usage object, and streaming over server-sent events.
The practical consequence: any library written for OpenAI works against such a service with no logic changes. Two values change — the address and the key.
Why it matters
- A single interface to models from different vendors — no per-vendor client to write.
- Tools with a "base URL" field connect without touching code.
- Switching models means changing a string in the request, not rewriting the integration.
- Existing SDKs, wrappers and frameworks keep working.
Code examples
from openai import OpenAI client = OpenAI( base_url="https://api.tokenator.top/v1", api_key="sk-your-tokenator-key", ) resp = client.chat.completions.create( model="gpt-5.5", messages=[{"role": "user", "content": "Hello"}], ) print(resp.choices[0].message.content)
import OpenAI from "openai"; const client = new OpenAI({ baseURL: "https://api.tokenator.top/v1", apiKey: "sk-your-tokenator-key", }); const resp = await client.chat.completions.create({ model: "gpt-5.5", messages: [{ role: "user", content: "Hello" }], }); console.log(resp.choices[0].message.content);
Note that base_url includes the /v1 suffix, and the SDK method appends /chat/completions to it.
What Tokenator supports
| Method | Path | Purpose |
|---|---|---|
| POST | /v1/chat/completions | The main OpenAI-format chat endpoint. Supports streaming, tools and multimodal input. |
| POST | /v1/responses | The Responses API format. Supports conversation continuation via previous_response_id. |
| POST | /v1/messages | The Anthropic Messages format. Also available under the /anthropic/v1/messages prefix. |
| POST | /v1/messages/count_tokens | Token counting for an Anthropic-format request. |
| POST | /v1/embeddings | Text embeddings. |
| POST | /v1/images/generations | Image generation. |
| POST | /v1/images/edits | Image editing and upscaling. Accepts multipart and JSON with base64. |
| POST | /v1/audio/speech | Speech synthesis. |
| POST | /v1/audio/transcriptions | Speech recognition. |
| POST | /v1/audio/translations | Recognition with translation into English. |
| GET | /v1/models | The list of models available to a given key. |
| GET | /v1/tokens | The key's remaining limit and spent tokens. |
Beyond the OpenAI format there is an Anthropic-compatible entry point. That helps tools originally written for Claude: they need no compatibility layer, yet the model can be any one from the catalog.
Where compatibility ends
Format compatibility does not mean every model can do the same things. Image input, tools and reasoning depend on the specific model and upstream, not on the request format. Check a model's page in the catalog for what it supports.
One more difference from talking to OpenAI directly: client-side server tools for web search and web fetch are stripped from the request, and upstream error texts are replaced with a generic message.
FAQ
Do I have to use the official OpenAI SDK?
No. Any HTTP client works: what matters is the request format, not the library.
Does streaming work?
Yes, via "stream": true and server-sent events — the same as with OpenAI.
Does the usage field match the real spend?
usage reports raw upstream tokens. The key limit is charged that value multiplied by the model multiplier.