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

Python (openai)
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)
TypeScript (openai)
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

MethodPathPurpose
POST/v1/chat/completionsThe main OpenAI-format chat endpoint. Supports streaming, tools and multimodal input.
POST/v1/responsesThe Responses API format. Supports conversation continuation via previous_response_id.
POST/v1/messagesThe Anthropic Messages format. Also available under the /anthropic/v1/messages prefix.
POST/v1/messages/count_tokensToken counting for an Anthropic-format request.
POST/v1/embeddingsText embeddings.
POST/v1/images/generationsImage generation.
POST/v1/images/editsImage editing and upscaling. Accepts multipart and JSON with base64.
POST/v1/audio/speechSpeech synthesis.
POST/v1/audio/transcriptionsSpeech recognition.
POST/v1/audio/translationsRecognition with translation into English.
GET/v1/modelsThe list of models available to a given key.
GET/v1/tokensThe 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.