OpenAI-compatible API: a drop-in replacement for your stack

Most of the tooling you already use — the OpenAI SDKs for Python, Node, and Go, plus frameworks like LangChain, LlamaIndex, and most function-calling libraries — speaks a single dialect: the OpenAI request format. That dialect has quietly become the industry default, and it is why "OpenAI-compatible" matters so much.

What "OpenAI-compatible" actually means

An OpenAI-compatible API accepts the same request and response shapes as the OpenAI API:

• POST /v1/chat/completions for chat, with a messages array.
• Streaming via stream: true and server-sent events.
• The same choices, usage, and finish_reason fields on the way back.

Because the format matches, code written for OpenAI works unmodified against a compatible endpoint. You do not import a new SDK or rewrite your prompt plumbing.

The one-line migration

For most SDKs the switch is a single change. Point the base URL at the gateway and keep everything else:

from openai import OpenAI

client = OpenAI(
    api_key="your-mappace-key",
    base_url="https://mappace.com/v1",
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Hello!"}],
)

The same pattern holds in the Node SDK: set baseURL on the client constructor, and your existing calls, retries, and test fixtures keep working.

Non-OpenAI models, same shape

The useful trick of a gateway is that even models from Anthropic or Google — whose native APIs look nothing like OpenAI's — are exposed through the same /v1/chat/completions shape. The gateway translates your OpenAI-style request into whatever each backend expects, and translates the response back. To your code, every model is just another model name.

This is what makes "drop-in" more than a marketing phrase: you do not just skip re-writing for OpenAI, you skip re-writing for every provider at once.

What the format does not guarantee

Compatibility is about the transport, not about feature parity. A few things to check before you assume an endpoint is fully interchangeable:

• Tool calling and structured output: JSON schema support can differ slightly between backends.
• Model names: use the gateway's catalog names, which map to the right upstream model.
• Streaming format: most endpoints stream SSE the same way, but verify your client parses deltas correctly.
• Parameter support: not every backend honors every temperature, top_p, or max_tokens value identically.

None of these are blockers — they are the exact differences a gateway normalizes for you.

Migrating frameworks that assume OpenAI

Popular frameworks make a hard assumption that "the LLM" is the OpenAI API, which works in your favor here. LangChain and LlamaIndex both let you point their OpenAI-backed classes at a custom base URL; tools that support embeddings and chat through separate endpoints can be pointed at the same gateway. The migration is usually a config change, not a code change — which is the entire value proposition of a compatible layer.

One more thing worth checking is embeddings. If your stack calls an embeddings endpoint alongside chat completions, confirm the gateway exposes that route too, so your retrieval pipeline and your chat calls share the same key and base URL instead of splitting across two integrations.

Testing your migration in minutes

The fastest way to confirm your stack is compatible is to send one request and inspect the response shape against what your code expects:

curl https://mappace.com/v1/chat/completions \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "ping"}]}'

If the returned choices, usage, and finish_reason fields line up with what your SDK parses, you are done. Then test one streaming call, because streaming is where subtle client bugs tend to hide.

Verify it before you commit

Send your first request against the API reference, or browse the model catalog to pick the models your code should default to.