{"id":47,"date":"2026-09-16T01:38:00","date_gmt":"2026-09-15T17:38:00","guid":{"rendered":"https:\/\/wp.qoraapi.com\/openai-compatible-api-guide\/"},"modified":"2026-09-17T00:27:39","modified_gmt":"2026-09-16T16:27:39","slug":"openai-compatible-api-guide","status":"publish","type":"post","link":"https:\/\/qoraapi.com\/blog\/openai-compatible-api-guide\/","title":{"rendered":"OpenAI-Compatible API: One Key for GPT, Claude & Gemini"},"content":{"rendered":"\n

An OpenAI-compatible API<\/strong> is any HTTP endpoint that accepts the same \/v1\/chat\/completions<\/code> request format, JSON schema, and authentication pattern used by OpenAI, so the official OpenAI SDKs (Python, Node.js, Go, .NET, Java, curl, and the community ecosystem around them) can be pointed at it by changing only one line: the base_url<\/code>. The response is the same JSON shape, the streaming protocol is the same Server-Sent Events format, and the model is selected by a string you pass in the request body. This is what allows a single piece of client code to talk to OpenAI’s own servers, to a private Azure deployment, to Anthropic Claude routed through an aggregator, to Google Gemini, to open-source models, or to a relay such as Qora API \u2014 with zero changes to your application logic.<\/p>\n\n\n\n

This guide explains what an OpenAI-compatible API is in practice, how it works under the hood, and why it has become the de-facto interface for modern AI integrations. It also shows the exact code you need to start sending requests today, and how to use the same key to call GPT, Claude, and Gemini through one endpoint.<\/p>\n\n\n\n

What is an OpenAI-compatible API?<\/h2>\n\n\n\n

An OpenAI-compatible API is an endpoint that mimics OpenAI’s public HTTP interface. The most common surface is the Chat Completions endpoint:<\/p>\n\n\n\n

POST https:\/\/<your-provider>\/v1\/chat\/completions\nContent-Type: application\/json\nAuthorization: Bearer YOUR_API_KEY\n\n{\n  \"model\": \"gpt-4o\",\n  \"messages\": [\n    {\"role\": \"system\", \"content\": \"You are a helpful assistant.\"},\n    {\"role\": \"user\", \"content\": \"Summarise this document in 3 bullets.\"}\n  ],\n  \"temperature\": 0.3,\n  \"stream\": false\n}<\/code><\/pre>\n\n\n\n
Any service that returns a response in the same shape as OpenAI’s \/v1\/chat\/completions<\/code> is “OpenAI-compatible”. The OpenAI SDKs are designed to work against this contract, so an OpenAI-compatible endpoint can be used with the official SDKs, with LangChain, with LlamaIndex, with Cursor, with Continue.dev, with countless internal tools, and with simple curl<\/code> commands \u2014 without modifying the client.<\/p>\n\n\n\n
Providers that typically expose an OpenAI-compatible API include OpenAI itself, Azure OpenAI (with \/openai\/deployments\/<name><\/code>), Together AI, Groq, Fireworks, DeepSeek, OpenRouter, and AI-relay \/ aggregation platforms such as Qora API. Each provider usually accepts a different set of model<\/code> names \u2014 for example gpt-4o<\/code>, claude-3-5-sonnet<\/code>, gemini-1.5-pro<\/code>, or vendor-specific aliases \u2014 but the request envelope, authentication header, and response JSON are identical.<\/p>\n\n\n\n
Why an OpenAI-compatible API matters<\/h2>\n\n\n\n
For developers and teams shipping AI features, the OpenAI-compatible contract is the closest thing the industry has to a standard interface for LLMs. There are several practical reasons it has become so widely adopted:<\/p>\n\n\n\n
    \n
  1. SDK portability.<\/strong> The official OpenAI libraries for Python, JavaScript, Go, Java, and .NET work out of the box against any compatible endpoint. You can keep using the same client object, retry logic, and tooling across providers.<\/li>\n
  2. No vendor lock-in.<\/strong> Switching from one provider to another becomes a configuration change rather than a rewrite. If a model is deprecated, prices change, or latency worsens on one provider, you can move the same workload elsewhere in minutes.<\/li>\n
  3. Multi-model workflows.<\/strong> Different models are better at different tasks. Coding assistants often perform better with Claude, structured extraction with GPT, and long-context summarisation with Gemini. An OpenAI-compatible gateway lets you route different parts of the same product to different models \u2014 and benchmark them in production.<\/li>\n
  4. Unified billing and keys.<\/strong> Instead of managing a separate account, key, and invoice for each upstream provider, you can manage one key and one balance against an aggregator that speaks the OpenAI protocol.<\/li>\n
  5. Regional and access considerations.<\/strong> Many teams need to access models from locations or accounts where direct upstream access is not available. A relay that exposes the OpenAI protocol removes this friction without changing how the client is written.<\/li>\n<\/ol>\n\n\n\n
    How an OpenAI-compatible API works<\/h2>\n\n\n\n
    From a developer’s point of view the flow is straightforward. Your application sends a Chat Completions request to a single URL, identifies itself with a Bearer token, and names the model it wants. The provider authenticates the request, looks up the model in its routing table, forwards the request to the correct upstream (OpenAI, Anthropic, Google, an open-source host, or its own inference stack), and returns the result in the same JSON envelope OpenAI uses.<\/p>\n\n\n\n
    The diagram below summarises the flow. The application on the left never needs to know which provider is on the other side \u2014 it only knows the base_url<\/code> and a model name.<\/p>\n\n\n\n
    \"Diagram<\/figure>\n\n\n\n
    For a deeper explanation of the broader category, see our guide on what an AI API gateway is<\/a>, and the practical steps to integrate an AI API<\/a> into a real application.<\/p>\n\n\n\n
    One endpoint for GPT, Claude and Gemini<\/h2>\n\n\n\n
    The most useful feature of an OpenAI-compatible API is that the same code path can call multiple models. You choose the model per request \u2014 or per feature in your product \u2014 without redeploying anything. The table below shows what an OpenAI-compatible payload looks like across the three most popular model families.<\/p>\n\n\n\n
    Model family<\/th>Example model string<\/th>Best for<\/th><\/tr><\/thead>
    OpenAI GPT<\/td>gpt-4o<\/code>, gpt-4o-mini<\/code>, o1-mini<\/code><\/td>General reasoning, tool use, structured output<\/td><\/tr>
    Anthropic Claude<\/td>claude-3-5-sonnet<\/code>, claude-3-haiku<\/code><\/td>Long-form writing, nuanced instruction following, code review<\/td><\/tr>
    Google Gemini<\/td>gemini-1.5-pro<\/code>, gemini-1.5-flash<\/code><\/td>Long context, multimodal input, fast and cheap responses<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Behind the scenes, an aggregator translates the OpenAI-shaped payload into the format each upstream provider expects (Anthropic’s \/v1\/messages<\/code> and Google’s generateContent<\/code> both use different request and response shapes), runs the call, and normalises the answer back to the OpenAI shape your client expects. Your application sees one consistent response no matter which model answered.<\/p>\n\n\n\n
    Code examples you can paste today<\/h2>\n\n\n\n
    These three snippets are identical in structure \u2014 the only thing that changes between providers is base_url<\/code> and the model<\/code> string. Replace the placeholder with a key from any OpenAI-compatible provider (here we use Qora API as the example) and the same code calls GPT, Claude, or Gemini.<\/p>\n\n\n\n
    cURL<\/h3>\n\n\n\n
    curl https:\/\/api.qoraapi.com\/v1\/chat\/completions \\\n  -H \"Authorization: Bearer $QORA_API_KEY\" \\\n  -H \"Content-Type: application\/json\" \\\n  -d '{\n    \"model\": \"gpt-4o\",\n    \"messages\": [\n      {\"role\": \"user\", \"content\": \"Explain OpenAI-compatible APIs in one paragraph.\"}\n    ]\n  }'<\/code><\/pre>\n\n\n\n
    Python (official OpenAI SDK)<\/h3>\n\n\n\n
    from openai import OpenAI\n\nclient = OpenAI(\n    base_url=\"https:\/\/api.qoraapi.com\/v1\",   # <-- the only line that changes\n    api_key=\"YOUR_API_KEY\",\n)\n\nresp = client.chat.completions.create(\n    model=\"claude-3-5-sonnet\",                # <-- swap to gpt-4o or gemini-1.5-pro\n    messages=[\n        {\"role\": \"system\", \"content\": \"You are a concise technical writer.\"},\n        {\"role\": \"user\", \"content\": \"Summarise what an OpenAI-compatible API is.\"},\n    ],\n)\nprint(resp.choices[0].message.content)<\/code><\/pre>\n\n\n\n
    Node.js (official OpenAI SDK)<\/h3>\n\n\n\n
    import OpenAI from \"openai\";\n\nconst client = new OpenAI({\n  baseURL: \"https:\/\/api.qoraapi.com\/v1\",     \/\/ <-- the only line that changes\n  apiKey: process.env.QORA_API_KEY,\n});\n\nconst completion = await client.chat.completions.create({\n  model: \"gemini-1.5-pro\",                    \/\/ <-- swap to any supported model\n  messages: [\n    { role: \"user\", content: \"Give me 3 use cases for an AI API gateway.\" },\n  ],\n});\n\nconsole.log(completion.choices[0].message.content);<\/code><\/pre>\n\n\n\n
    The same pattern works in LangChain (ChatOpenAI(base_url=...)<\/code>), LlamaIndex, and the Cursor \/ Continue VS Code extensions. If your tool already speaks OpenAI, you can switch the underlying model by changing two values: the base URL and the model name.<\/p>\n\n\n\n
    How to pick an OpenAI-compatible provider<\/h2>\n\n\n\n
    Not every “compatible” provider is identical. When you evaluate one, look at these criteria:\n<\/p>\n\n\n\n