# What is an OpenAI-compatible API?

> An OpenAI-compatible API implements one or more HTTP routes and response shapes used by OpenAI clients, so an application can often change the base URL, API key, and model ID instead of replacing its SDK. Compatibility is operation-specific: supporting Chat Completions does not automatically imply Responses, embeddings, images, tools, or every parameter.

_Last reviewed 2026-08-15 · [Editorial review](https://keeprouter.com/editorial-policy#editorial-team)_

## The three configuration changes

Most compatible SDK migrations begin with:

```python
client = OpenAI(
    base_url="https://keeprouter.com/v1",
    api_key="sk-kr-your-key",
)
```

The request still uses an SDK method such as `chat.completions.create`, but the model must be a canonical ID available on that route. The [model catalog](/models) is the current authority for route and ID, while the [OpenAPI document](/api/openapi.json) describes the gateway contract.

## A compatibility checklist

Confirm the exact endpoint, authentication header, request fields, streaming event sequence, terminal usage record, tool-call continuation, error body, timeout behavior, and output-token limit. Run the real production payload: a provider can accept a small plain message while rejecting a tool, image, reasoning, or structured-output field.

## Chat Completions and Responses are separate

Chat Completions uses message arrays and choice-oriented responses. The Responses API has a different top-level object, input/output item model, reasoning options, and semantic stream events. A gateway may support both, but a model must have an eligible route for the one your client calls.

## What a base URL change cannot promise

It cannot guarantee identical tokenization, safety behavior, tool quality, context handling, latency, or output. Provider-specific parameters may be ignored, translated, or rejected. Treat compatible syntax as an integration accelerator and keep model acceptance in evaluation tests.

## Migration order

Test deterministic non-streaming first, then streaming, then tools or structured output, then a representative workload. Put base URL and model in configuration, scope the key, and retain the old path until rollback is proven.

## Frequently asked questions

### Can I keep the official OpenAI SDK?

Usually yes for the routes the compatible service implements; change its base URL, key, and model.

### Does compatible mean identical?

No. Request shape can be compatible while capabilities and model behavior differ.

### Are all OpenAI routes included?

No. Each service and model supports a specific set of routes and operations.

### What should I test first?

Start with non-streaming, then streaming, tools, usage, errors, and the exact production payload.

## Sources reviewed

1. [OpenAI API reference](https://platform.openai.com/docs/api-reference)

## Related guides

- [OpenAI-compatible API](https://keeprouter.com/features/openai-compatible-api.md)
- [openai sdk](https://keeprouter.com/use-cases/openai-sdk.md)
- [OpenAI-compatible API migration checklist](https://keeprouter.com/blog/openai-compatible-api-migration-checklist.md)
- [Responses API vs Chat Completions: choose by contract, not novelty](https://keeprouter.com/blog/responses-api-vs-chat-completions.md)

## Verify it with the live product

Check the live model catalog, create a free-scoped key, and inspect the resulting request evidence.

[Create a free key](https://keeprouter.com/login?returnTo=%2Fconsole%2Fkeys%3Fmodel%3Dfree) · [Live models and pricing](https://keeprouter.com/models.md)