An OpenAI-compatible API fits clients that already use the OpenAI SDK, Chat Completions, or Responses. An Anthropic-compatible API fits tools and applications that expect the Messages API format. Compatibility reduces integration work, but it does not guarantee identical models, parameters, streaming events, tool use, or errors. Choose the protocol from the client's contract, then test a real request before moving production traffic.

What API-Compatible Actually Means

A compatible API accepts a familiar request shape and returns a response that an existing SDK or client can parse. In a typical integration, the developer changes the Base URL, API Key, and Model ID while keeping most application code.

That term has a clear boundary. A provider may support basic text generation without supporting a particular parameter, hosted tool, audio, image endpoint, or exact error semantics. Even two endpoints that expose a model field may differ in how they list models and grant access to them.

Want to test the selected protocol with a real request? You can create your own BetterToken account and API key, open the quickstart, and send one minimal test. BetterToken provides separate OpenAI-compatible and Anthropic-compatible interfaces; the protocol, Base URL, API key type, and current Model ID must match the current API reference.

How Requests and Authentication Differ

In an OpenAI-compatible flow, a client normally builds messages for Chat Completions or input for Responses. Authentication commonly uses a Bearer token:

Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

Anthropic Messages uses its own message structure, a separate system field, a required output limit, and a protocol version. Anthropic's official API uses headers such as x-api-key and anthropic-version:

x-api-key: YOUR_API_KEY
anthropic-version: CURRENT_SUPPORTED_VERSION
Content-Type: application/json

A compatible gateway may accept a different authentication scheme. Take headers from the documentation for the endpoint you are calling. An official API example explains the protocol format; it does not replace the provider's integration guide.

The system instruction also has a different place in each contract. One protocol may keep it among messages, while another sends it as a separate field. Mechanical conversion can change context order, a cache prefix, or client behavior.

Chat Completions, Responses, and Messages Are Different Contracts

The phrase OpenAI-compatible does not say which interface is implemented. Record the exact contract before a migration:

Chat Completions: a messages array, a response under choices, and streamed fragments under delta.
Responses API: input items, typed output items, and separate response lifecycle events.
Anthropic Messages: messages, a separate system field, content blocks, and its own stream events.

If a library expects Responses, an endpoint that only implements /chat/completions is insufficient. If Claude Code expects Anthropic Messages, an OpenAI-compatible endpoint does not work without an adapter. Replacing the Base URL is enough only when client and server implement the same contract.

How Streaming and Completion Differ

All three interfaces can stream data, but their event names and ordering differ.

The Responses API sends typed Server-Sent Events for response creation, output text fragments, and terminal states. A client must wait for a completion event or handle a failed or incomplete response.

Anthropic Messages sends message_start, content-block events, message_delta, and message_stop. An error can arrive inside an already-open stream after the initial HTTP response succeeded.

With Chat Completions, the client normally accumulates choices[0].delta and detects the end according to that endpoint's contract. Code that waits for only one marker cannot be copied into Responses or Messages without verification.

A minimal handler keeps four states:

created -> receiving -> completed
                   \-> failed
                   \-> disconnected

disconnected is not completed. If the connection ends after a partial response, preserve the events already received and decide whether a retry is safe.

Tool Use and Structured Output

Similar field names such as tools and tool_calls can imply more compatibility than actually exists. Test at least:

JSON Schema and supported type restrictions;
parallel tool calls;
how a tool result is sent back to the model;
assembly of streamed arguments;
behavior on invalid JSON;
strict structured output and schema refusals.

An adapter must preserve the meaning of a call, not just rename fields. This matters most for tools with side effects: repeating the same tool call can send a second message, create another record, or execute an operation twice.

Do Not Map Errors by HTTP Status Alone

401, 403, 404, 429, and 5xx provide a useful first classification, but error bodies and headers differ by provider. Preserve:

HTTP status;
provider error type and code;
a short message without secrets;
request ID;
retry-related headers;
endpoint, protocol, and Model ID.

Do not log the API Key, full prompt, or sensitive response. If a gateway normalizes errors, preserve the original provider code in a safe internal field. Otherwise model not found, missing access, and a mismatched endpoint may all collapse into an unhelpful 400.

How to Choose the Protocol

A ready-made AI tool

Read the tool documentation first. If it asks for an OpenAI Base URL and uses Chat Completions or Responses, choose the corresponding OpenAI-compatible endpoint. If it reads ANTHROPIC_BASE_URL and expects Messages, use an Anthropic-compatible endpoint.

Do not choose a protocol from the model name. A model may be available through a gateway while the client still requires one specific request format.

Your own application

The decision depends on the SDK and features you already use. For a new application, list required capabilities: streaming, tools, structured output, vision, token usage, batch operations, or other endpoints. Verify each item in the provider's official documentation.

A provider migration

Estimate the surface of the contract, not the number of changed lines. Basic chat may need only three new configuration values. An agent application with tools, long history, cache, and streaming usually needs an adapter and integration tests.

Test Before Moving Production Traffic

Record the SDK, endpoint, and API version.
Copy the exact Model ID from the current catalog.
Send a short request without tools or streaming.
Stream a basic answer through its terminal event.
Run a safe tool call with no external side effect.
Trigger a controlled error with a deliberately invalid Model ID.
Match usage, status, and request ID with the Dashboard.
Test timeout handling and a bounded retry.

Only then move real traffic. With BetterToken, start from the API reference, choose one protocol, and confirm a minimal request before enabling agent tools.

FAQ

Does an OpenAI-compatible API fully reproduce the OpenAI API?

No. The term refers to compatibility with a specific interface. Models, parameters, tools, streaming, errors, and additional endpoints still require separate verification.

Can I call an Anthropic-compatible endpoint with the OpenAI SDK?

Not directly when the SDK sends the OpenAI contract. Use a client that supports Anthropic Messages or an adapter that correctly converts messages, streaming, and tool use.

Is replacing the Base URL enough?

Sometimes, for a short text request in an already-compatible client. For a production migration, still verify the Model ID, authentication, streaming, tools, errors, and usage.

Which protocol does Claude Code need?

Claude Code normally uses an Anthropic-compatible interface. Take the exact variables, Base URL, and model settings from the current BetterToken guide.

OpenAI-Compatible or Anthropic-Compatible API: Which One to Choose