What is an OpenAI-compatible API?
An OpenAI-compatible API accepts the request and response shapes of OpenAI's API, so any client built for OpenAI works by changing a base URL and a key. What compatibility covers, where it stops, and the other wire formats.
An OpenAI-compatible API is a service that accepts requests in the shape OpenAI's own API uses and answers in the same shape, so that software written against OpenAI works against it unchanged. In practice "unchanged" means two settings: the base URL the client sends requests to, and the API key it sends with them.
The shape became a standard by accident. OpenAI's API was the first one most developers wrote against, so the SDKs, the chat interfaces, the coding tools and the agent frameworks all learned its conventions. Every other provider and every self-hosted model server then had a choice between asking the world to learn a second format or speaking the first, and nearly all of them chose the first.
What the shape is
The core is POST /v1/chat/completions. The request carries a model id and a messages array of roles and content; the response carries the answer as a message, with a finish reason and token usage. Streaming sends the same thing as server-sent events, one chunk at a time. Tool calling adds a tools array of function schemas to the request and tool_calls to the response, with the caller executing the function and sending the result back as a message.
Around it sit GET /v1/models, which lists the ids a key may ask for and which many clients call on start-up to fill a menu, POST /v1/embeddings, and more recently the POST /v1/responses shape, which carries the same work in a newer form that some clients, the Codex CLI among them, speak instead.
What compatibility covers
A compatible endpoint handles the messages array with the usual roles, streaming, the common sampling parameters, tool calling and the model id. That is enough for the clients people actually use: Open WebUI, LibreChat, Cursor, Continue, the Vercel AI SDK, LangChain, and the official OpenAI SDKs in every language.
Where it gets thinner is at the edges. Vendor-specific fields (reasoning settings, caching hints, response formats) may be accepted, ignored or rejected. Some clients require /v1/models to answer before they will do anything. Image and audio inputs vary. And the model ids are whatever the endpoint decides they are, which is where a gateway can offer things no single provider has, such as an id that means "choose for me".
The other wire formats
Not everything speaks OpenAI's shape. The Anthropic Messages API is what Claude Code and the Anthropic SDKs use: content blocks rather than plain strings, a different streaming event format, a different tool-call shape. The Responses API is OpenAI's newer form. A service that wants to serve every client has to speak each of these, and a gateway that only speaks chat completions leaves those clients out.
Why it matters
Compatibility is what lets a team change what sits behind its tools without changing the tools. Point the same clients at a different base URL and they gain whatever the new endpoint adds, a different provider, routing, logging, a budget, or memory, with no code written.
Where Memtro fits
Memtro serves chat completions, the Responses shape and the Anthropic Messages shape at one base URL, with /v1/models listing auto, memtro and every provider model you hold a key for, and an optional memtro field in the request for the things OpenAI's shape has no word for. The API reference has the details.