DeepSeek API Integration Guide: Call DeepSeek via an OpenAI-Compatible Endpoint

DeepSeek is one of the most widely used open-weight model families, but accessing the official API directly often means dealing with regional network issues, separate billing, and another account to manage. Routing your DeepSeek calls through an OpenAI-compatible endpoint solves all three at once: you keep your existing OpenAI SDK code, your existing key-management habits, and gain access to the full DeepSeek lineup alongside every other model on the platform. This guide covers the practical path — where to get a key, what to put in base_url, working examples in curl, Python, and Node.js, how to handle the reasoning model's extra output field, and how to debug the five most common errors.

Prerequisites: get an API key

You need three things before your first call: an API key, the endpoint URL, and a model ID. The first two come from the platform console:

Register and log in

Create an account on EXAIV and log in to the console.

Generate an API key

Create a key on the API keys page. The full key is shown exactly once — copy and store it immediately.

Check your balance

New accounts typically include starter credits. Confirm a non-zero balance in the console before debugging. Billing and top-ups are handled on the pricing page.

The key is used exactly like an OpenAI key: send it in the Authorization: Bearer <your-key> header. One key works for every model — switching models only means changing the model field in the request body.

Endpoint and compatibility

The DeepSeek endpoint follows the OpenAI Chat Completions format:

The practical consequence: the official openai Python SDK, the openai Node.js SDK, LangChain, LobeChat, Dify, Cherry Studio, and any other tool that supports a custom OpenAI-compatible endpoint will work without a dedicated client library.

First call: verify with curl

Confirm your key and endpoint work before touching application code:

curl https://exaiv.com/api/ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {"role": "user", "content": "Introduce yourself in one sentence"}
    ]
  }'

The response follows the standard OpenAI shape with the text in choices[0].message.content. If this succeeds, your key, endpoint, and model ID are all correct — any later failure is unrelated to these three.

Python: the openai SDK

After installing the official SDK, only two parameters change:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://exaiv.com/api/ai/v1",
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": "You are a precise technical assistant"},
        {"role": "user", "content": "Explain what a context window is"},
    ],
)
print(resp.choices[0].message.content)

Migrating existing OpenAI code usually means changing exactly three things: base_url, api_key, and model. Standard Chat Completions features — function calling, JSON output, multi-turn conversations — work with unchanged syntax.

Node.js / TypeScript

const client = new OpenAI({
  apiKey: process.env.EXAIV_API_KEY,
  baseURL: "https://exaiv.com/api/ai/v1",
});

const resp = await client.chat.completions.create({
  model: "kimi-k3",
  messages: [{ role: "user", content: "Write a TypeScript quicksort" }],
});
console.log(resp.choices[0].message.content);

Read the key from an environment variable rather than committing it. The Node SDK works with all the conventions you already know.

Streaming

Streaming differs only in the request parameter and how you consume the response:

stream = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "Tell me a short story"}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta
    if delta and delta.content:
        print(delta.content, end="", flush=True)

In streaming mode, text arrives incrementally in delta.content. For web applications, forward chunks straight to the frontend for a typewriter effect instead of buffering the full response.

The reasoning model: deepseek-r1-0528 and reasoning_content

Some models in the catalog are reasoning models: they produce an internal thinking process before answering. When the model you call supports it, that process arrives in a dedicated field:

• Non-streaming: choices[0].message.reasoning_content holds the thinking text; content holds the final answer
• Streaming: increments arrive separately in delta.reasoning_content and delta.content

The handling rule is simple: always read the final answer from content. The reasoning_content field is process text — safe to display or log, but do not feed it back into the next turn's conversation history.

resp = client.chat.completions.create(
    model="kimi-k3",  # substitute the reasoning-capable ID from your live catalog
    messages=[{"role": "user", "content": "Which is larger, 9.11 or 9.8?"}],
)
msg = resp.choices[0].message
print("Thinking:", (msg.reasoning_content or "")[:200])
print("Answer:", msg.content)

Reasoning models typically consume more tokens and take longer to respond. They fit math, code review, and logic-heavy tasks; for everyday questions, a non-reasoning model responds faster. Not every model populates reasoning_content — check the model card before depending on it.

Model ID reference (DeepSeek family)

The table below is a DeepSeek-family reference. Many of these IDs are now in the EXAIV catalog (check /models for live availability); others remain for third-party channels and local deployment. For actual calls, use the live catalog's IDs:

Selection logic: long documents and large codebases go to the V4 family (million-token context); everyday conversation and batch text tasks go to the classic line; math and complex reasoning go to R1. For a scenario-by-scenario breakdown, see the model selection guide listed under further reading.

Troubleshooting common errors

401 Unauthorized. The key is invalid or malformed. Check three things: the key was copied completely with no stray whitespace, the header uses the Authorization: Bearer prefix, and the key has not been revoked. Generating a fresh key is the fastest way to test.

404 Not Found. Almost always a base_url problem. Common mistakes: using https://exaiv.com (missing /api/ai/v1), or stacking an extra /v1 to produce /api/ai/v1/v1. The SDK's base_url should end at /api/ai/v1 — the SDK appends the path itself.

429 Too Many Requests. You hit a rate limit. Apply exponential backoff with retries first; if it persists, lower your concurrency or contact the platform about higher limits.

Context length errors. The error message usually mentions context length. Check two things: the total length of your messages array against the model's window (see the table above), and whether you accidentally included a previous turn's reasoning_content in the history.

Balance errors. Calls fail when the console balance is exhausted; balances never go negative. Topping up restores service immediately — keys and configuration are unaffected.

Migration checklist

If DeepSeek traffic currently flows through another channel, migrating to the compatible endpoint takes four checks:

1. Swap base_url and key to the values in this guide
2. Align model IDs — the same model can carry different names on different platforms; the table above is the source of truth here
3. Replay a regression set — take five to ten real production prompts and compare answer quality and latency
4. Smoke-test streaming and function calling if your product depends on them

Migration does not require downtime: run both channels in parallel and shift traffic gradually.

FAQ

Further reading

• Chat Completions API reference — request and response format in detail
• How to choose a DeepSeek model — scenario-based selection across the lineup
• Pricing — live prices and top-up plans
• Dify integration — build apps without code