OneKeyModel LogoOneKeyModel
Back to blog
OpenAI-Compatible APIOpenAI SDKDeepSeekQwen

What Is an OpenAI-Compatible API: Why Changing base_url and api_key Can Switch Models

Published May 10th, 2026

Many people see "OpenAI-compatible API" and assume it means the official OpenAI API.

It does not.

More accurately, it means an API that follows a familiar OpenAI-style request format. Your code can keep using the OpenAI SDK, but the request may go to another platform that supports the same shape.

The benefit is simple: if your project already uses the OpenAI SDK, moving to models such as Qwen or DeepSeek often does not require rewriting everything.

It is not the official OpenAI API, and it does not mean GPT support

This is worth saying first.

OpenAI-compatible means the interface format is compatible. It does not mean the model is from OpenAI.

A platform can support OpenAI SDK-style calls while actually serving DeepSeek, Qwen, or other models.

Because of policy and integration constraints, OneKeyModel currently does not support GPT, Claude, or Gemini. For now, the practical path is to use available models such as Qwen and DeepSeek on real tasks.

If you want the broader checklist for Russian users before connecting an AI API, read the AI API checklist. This guide focuses on migration and code.

The two settings you usually change

In many migration cases, the main changes are:

api_key="your-api-key"
base_url="https://api.onekeymodel.com/v1"

api_key proves who you are. base_url decides where the request goes.

The model is selected with the model parameter:

model="deepseek-chat"

So the idea is simple: the SDK stays familiar, the endpoint changes, and the model name changes.

Python example

from openai import OpenAI

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

response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "user", "content": "Rewrite this note as natural Russian copy"}
    ]
)

print(response.choices[0].message.content)

The important part is not that it "looks like OpenAI". The important part is that migration is easier. You do not need to learn a totally different SDK before testing a model.

JavaScript example

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "your-api-key",
  baseURL: "https://api.onekeymodel.com/v1",
});

const response = await client.chat.completions.create({
  model: "deepseek-chat",
  messages: [
    { role: "user", content: "Generate 5 short product titles in Russian." },
  ],
});

console.log(response.choices[0].message.content);

If you have built a dashboard, Telegram bot, or automation script before, this style should feel familiar.

Do not build a big wrapper first. Make the shortest request work, then decide how to place it inside your project.

What changes when you switch models?

Start with three fields:

  • base_url: the API endpoint;
  • api_key: your key;
  • model: the model name you want to call.

For example, you may use deepseek-chat today. Later, when more models are available, you may only need to change the model value and test the same request flow again.

That is the practical value of an OpenAI-compatible API: business logic changes less, while model comparison becomes easier.

Do not change too many things at once. Keep the same input, change one model name, then compare quality, speed, and cost. That way you know the difference comes from the model, not from a rewritten workflow.

What are messages?

Many beginners get paused by messages.

You can think of it as the conversation you send to the model.

The simplest version is:

messages=[
    {"role": "user", "content": "Write a product description"}
]

If you want to give the model some context, add a system message:

messages=[
    {"role": "system", "content": "You are an editor who writes natural Russian copy"},
    {"role": "user", "content": "Rewrite this Chinese note as Russian ad copy"}
]

Do not make the prompt complicated at the beginning. First check whether the model can do the core task, then tune tone, format, and rules.

Common mistakes

Most errors are very ordinary:

  • base_url is missing /v1 or has it twice;
  • the API key has a copied space;
  • the model name is wrong;
  • balance is not enough;
  • the request is too long;
  • the messages format is wrong;
  • streaming and non-streaming code are mixed;
  • test and production keys are mixed;
  • old environment variables still point to another provider.

For the first integration, keep the code short. Run one request before putting it inside a bigger application.

When you get an error, read more than the last line. It often tells you whether the problem is authentication, missing model, insufficient balance, request format, or rate limits.

Where this is useful

OpenAI-compatible APIs are especially useful when you:

  • already use the OpenAI SDK;
  • want to connect a Telegram bot;
  • want to use LangChain, Dify, LlamaIndex, or similar tools;
  • want to add AI to an internal dashboard;
  • want to batch-process translation, summaries, or copy;
  • want to compare Qwen, DeepSeek, and other available models.

If your main goal is finding an OpenRouter alternative, read the OpenRouter alternative guide. If you already plan to connect an API, this page is the technical starting point.

Bottom line

An OpenAI-compatible API is not mysterious. It solves migration cost: you do not need to rewrite your SDK, tools, and business logic just to test a different model.

For developers, that means faster experiments. For teams, that means less maintenance. For content and operations workflows, that means AI can enter real tools more easily.

Start with one simple request, then compare models, control cost, and move into the project step by step.