You signed up at platform.deepseek.com, generated a key, pasted it into your script, and the response came back as a 401. Or your code worked yesterday and stopped working today. DeepSeek API authentication is short on surprises once you understand the model: a single secret key sent as an HTTP Bearer token on every request, against an OpenAI-compatible endpoint at `https://api.deepseek.com`. There is no OAuth flow, no signed request, no token-exchange dance. The complexity lives in how you store, rotate, scope, and recover that key — and in distinguishing authentication failures (401) from billing failures (402) when something breaks. This guide walks through the full authentication surface, with working Python and curl examples, security patterns I run in production, and the migration steps for the legacy `deepseek-chat` and `deepseek-reasoner` model IDs.

What DeepSeek API authentication actually is

DeepSeek uses a single authentication mechanism for its developer API: an API key transmitted in the standard HTTP Authorization header as a Bearer token. All APIs require authentication via Bearer Token. Get an API Key from the API Key Management Page, then add it to the request header as Authorization: Bearer YOUR_API_KEY. There is no separate signing step, no HMAC, no rotating session token. The server validates the key on each request and either accepts it or returns a 401.

Two things make that simple model worth a dedicated article. First, DeepSeek’s API is wire-compatible with OpenAI’s Chat Completions surface and (since the V4 launch on April 24, 2026) Anthropic’s Messages surface. The DeepSeek API uses an API format compatible with OpenAI/Anthropic. By modifying the configuration, you can use the OpenAI/Anthropic SDK or software compatible with the OpenAI/Anthropic API to access the DeepSeek API. That means the same Bearer key authenticates two distinct request shapes. Second, the API is stateless — every request must carry both the key and the full conversation history. There is no session you log into; the header is the entire handshake.

Quickstart: authenticate your first request

Below is the minimum viable authenticated request, in two forms. Both target the canonical chat endpoint POST /chat/completions on https://api.deepseek.com. Set DEEPSEEK_API_KEY as an environment variable before running either snippet.

curl

curl https://api.deepseek.com/chat/completions 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" 
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Hello!"}
    ],
    "stream": false
  }'

Python with the OpenAI SDK

The official OpenAI Python SDK works against DeepSeek by changing only base_url and api_key. Install it with pip install openai, then:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ.get("DEEPSEEK_API_KEY"),
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Hello"},
    ],
    stream=False,
    reasoning_effort="high",
    extra_body={"thinking": {"type": "enabled"}},
)
print(response.choices[0].message.content)

The reasoning_effort parameter and the extra_body thinking flag are V4 features — they switch either V4 model into thinking mode, which returns reasoning_content alongside the final content. Authentication itself is the same regardless of mode. For the full request reference, see our DeepSeek API documentation guide.

Where keys live: the platform.deepseek.com console

Every key originates in the developer console. Go to platform.deepseek.com — this is the API platform where you manage your keys, billing, and usage. Sign up with your email or phone number. Once you’re in, you’ll land on the dashboard. Before your API key will work, you need to add a payment method and top up your balance. The console exposes three things you need: account billing (top up before the key will pass billing checks), usage telemetry, and the key-management page itself.

Creating a key is a two-click affair. In the left sidebar, click API keys, then click Create new API key. Give your key a descriptive name like my-app-dev so you can identify it later, then confirm. Important: Copy the key immediately. DeepSeek only shows it once. If you lose the secret you cannot retrieve it from the console — you generate a new one and revoke the old. For the full sign-up walkthrough including billing, see our dedicated get a DeepSeek API key tutorial.

What a key looks like and what it can do

• Format: an opaque string prefixed for visual recognition. Treat it as a password — never log it, never embed it in client-side bundles.
• Scope: account-wide. A single key can call any model your account has access to. There are no fine-grained scopes (read-only, model-restricted, IP-restricted) at the time of writing.
• Expiry: keys do not expire on a schedule. They remain valid until you revoke them, your account is suspended, or DeepSeek invalidates them server-side.
• Rate-limiting: rate limits attach to the account, not the key, so generating multiple keys does not multiply your throughput. See our DeepSeek API rate limits reference for the dynamic-concurrency model DeepSeek uses.

The Authorization header in detail

The header has exactly one acceptable shape:

Authorization: Bearer sk-...your_key...

Common ways to get this wrong, in roughly the order I see them break in production:

1. Missing the literal word “Bearer”. Authorization: sk-... alone returns 401.
2. Wrong header name. DeepSeek does not honour X-API-Key, Api-Key, or query-string keys.
3. Whitespace or newlines in the key. Pasting from a terminal that wrapped the line is a classic source of “double-check that you have copied the key correctly, that it is not expired, and that it is formatted properly in the Authorization header as Bearer <your_api_key>”.
4. Stale environment variable. If you rotated the key but your serverless runtime cached the old value, requests look authenticated to your code and unauthenticated to DeepSeek.
5. Wrong account. Personal-account keys do not work against organisation workspaces and vice versa.

OpenAI vs Anthropic compatibility — same key, two surfaces

DeepSeek now exposes two SDK-compatible request formats against the same base URL and the same Bearer key. The API supports an OpenAI-compatible chat-completions format at https://api.deepseek.com and an Anthropic-compatible format at https://api.deepseek.com/anthropic. The authentication header is identical in both — only the request body schema differs.

If you already maintain an Anthropic-shape codebase, the Anthropic surface is the cheaper migration. Most new code should pick OpenAI-compatible. For a deeper treatment, see our DeepSeek OpenAI SDK compatibility reference.

Model IDs: V4 today, legacy until July 2026

Authentication is decoupled from the model you target, but the wrong model ID returns a 404 that looks like an auth failure to a casual reader. Use the current V4 IDs in new code:

• deepseek-v4-pro — frontier-tier MoE (1.6T total / 49B active parameters)
• deepseek-v4-flash — cost-efficient MoE (284B total / 13B active), the default recommendation for most chat workloads

The legacy IDs deepseek-chat and deepseek-reasoner are still accepted. The model names deepseek-chat and deepseek-reasoner will be deprecated on 2026/07/24. For compatibility, they correspond to the non-thinking mode and thinking mode of deepseek-v4-flash, respectively. Migrating is a one-line model= swap; the base_url and the Bearer key do not change. Plan the cutover before 2026-07-24 15:59 UTC, after which calls using the legacy IDs will fail. Detail on both tiers lives on our DeepSeek V4-Flash and DeepSeek V4-Pro pages.

Authentication errors and what they actually mean

DeepSeek separates authentication problems from billing problems with two distinct status codes, which matters because the fix is different in each case. The quick-start error list separates authentication problems from billing problems: a wrong or missing key leads to 401, while exhausted balance leads to 402. 401 Authentication Fails: The key is missing, malformed, incorrect, or no longer valid. 402 Insufficient Balance: Your account balance is not sufficient for the request.

A useful diagnostic when 401s appear out of nowhere: drop down to a curl call against GET /v1/models with your key. If that returns 200, your key is valid and the bug is in your client code. If it returns 401, the key itself is the problem. Our DeepSeek API error codes reference covers the full list.

Security patterns that matter in production

Bearer auth is only as safe as your key-handling discipline. The patterns below are the ones I run in production today, and the ones I check for when I review someone else’s integration.

Use environment variables, not source files

Hardcoding a key into config.py or a frontend bundle is the most common way keys leak. Read from os.environ in Python, process.env in Node, or a runtime secret manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, 1Password Secrets Automation). For a deeper code-level treatment, see DeepSeek Python integration.

Never expose the key in browsers or mobile binaries

Never expose a live API key in browser JavaScript, mobile binaries, public Git repositories, or screenshots. If your product is a web app, route requests through your own backend and forward sanitised responses to the client. The backend holds the Bearer key; the browser never sees it. The same rule applies to mobile — embedded keys can be extracted from a binary in minutes.

Rotate on a schedule and on incidents

I rotate production keys quarterly and immediately whenever a teammate leaves, a laptop is lost, or a CI secret is suspected of leaking. The flow is: generate the new key in the console, deploy it as the active secret, confirm telemetry shows traffic on the new key, then revoke the old. Because keys do not auto-rotate, this is a manual hygiene job — but it is cheap.

One key per environment, not per developer

Production, staging, and development each get their own key with a descriptive label (prod-2026-q2, staging, dev-shared). This makes the usage page legible and lets you revoke a single environment without nuking the others. Avoid one-key-per-developer; humans copy keys to laptops, phones, and shared scripts faster than you can audit them.

Watch billing and usage independently

A leaked key shows up first as anomalous spend, not as a 401. Set alerts on usage dashboards, and use a tool like our DeepSeek cost estimator to baseline what “normal” looks like for your workload before you go live.

Cost worked example: what an authenticated call costs

Authentication is free; the request body is not. Below is a transparent cost calculation for a typical chat workload on deepseek-v4-flash, the cost-efficient tier — 1,000,000 calls with a 2,000-token cached system prompt, a 200-token user message, and a 300-token response. Rates are per 1M tokens, as listed on the official DeepSeek API pricing page.

Input, cache hit  : 2,000,000,000 tokens × $0.028/M = $  56.00
Input, cache miss :   200,000,000 tokens × $0.14/M  = $  28.00
Output            :   300,000,000 tokens × $0.28/M  = $  84.00
                                                      --------
Total                                                 $ 168.00

The same workload on deepseek-v4-pro (frontier tier, $0.145 cache-hit / $1.74 cache-miss / $3.48 output per 1M) costs $1,682.00 — roughly ten times Flash. Pick Flash unless your benchmarks justify Pro. The cached-input line uses the cache-hit rate; the user message on each call is still an uncached miss against that prefix. Skipping the uncached line is the most common cost-modelling mistake I see.

Granted balances and free trials — read the small print

DeepSeek may offer a granted balance — a small promotional credit that can expire — and the dashboard sometimes displays a token allowance for new accounts. Reports across community guides describe both a free credit pool labelled at 5M tokens and 500M tokens for free at different points; the figure changes and is not a permanent feature. Check the billing console for current offers before you build a business case around it. There is no permanent free tier at the account level.

The API is stateless — auth doesn’t change that

Even with a valid Bearer key, the API does not remember anything about your previous calls. There is no session to authenticate into. Every POST /chat/completions request must include the full messages array — system prompt, prior user turns, prior assistant turns — for the model to have context. The web chat at chat.deepseek.com keeps history for you; the API does not. If you are coming from the chat UI, this is the single biggest behavioural difference. For a primer on stitching multi-turn conversations together correctly, see our DeepSeek API getting started tutorial.

Where to go next

Once your authentication is solid, the natural next steps are streaming, function calling, and JSON mode — all of which use the same Bearer header you already have. For the broader landscape of developer-facing pages, the DeepSeek API docs and guides hub indexes everything in one place.

Last verified: April 25, 2026. DeepSeek AI Guide is an independent resource and is not affiliated with DeepSeek or its parent company. Model IDs, pricing and API behaviour change; check the official DeepSeek documentation and pricing page before committing to a production decision.