DeepSeek API 402 Insufficient Balance: what to check first

Last updated 2026-09-19 · Written by Nova

Written by Nova · Last updated 2026-09-19 · AI assistance was used to draft and edit this post.

`` {"error":{"message":"Insufficient Balance","type":"insufficient_quota","code":"402"}} ``

If that's what came back, the good news is that nothing is wrong with your code. HTTP 402 is a billing-state answer: the request reached the provider, was understood, and was rejected because the account it's attached to has no spendable balance at that moment.

That's also the bad news. "Insufficient balance" is one message covering at least four different situations, and the right next move is different in each. Retrying doesn't help any of them; changing your code helps none of them.

The four situations behind one message

1. The account has never been funded. You've been running on trial credit and it's gone. This is the most common case and the easiest to confirm: the balance is zero or near-zero and never had a payment against it.

2. The account has been funded, but the payment hasn't been credited yet. You paid, the money left, and the balance still reads zero. This is not the same problem as case 1, and the fix is not "pay again" — paying again while a payment is in flight is how people end up with a double top-up.

3. You're on the wrong key or the wrong project. Some providers let one login hold several projects, each with its own balance. A key from an unfunded project produces exactly the same 402 as an unfunded account. If you've recently rotated keys or created a second project, check which one your OPENAI_API_KEY or DEEPSEEK_API_KEY actually points at before you assume the balance is the problem.

4. The request costs more than the remaining balance. A balance of a few cents is enough to pass a health check and not enough to run a long agent session with a large context. If short requests work and long ones 402, this is what you're looking at — the balance isn't empty, it's just smaller than the request.

Self-check 1: match your situation, then take one action

Work down the list and stop at the first line that describes you. Doing two of these at once is how a fixable problem turns into a support thread.

• Balance is zero and no payment was ever made → fund the account. Do not spend time on your code, your base URL, or your key format; 402 is not a configuration error and none of that is involved.
• A payment left your side recently (last hour or so) → wait before doing anything else. Blockchain transfers and card settlements are not instant, and a provider that credits on confirmation will show the balance a few minutes later. Check again in 10–15 minutes. Do not send a second payment in the meantime.
• A payment left your side hours ago and the balance is still zero → now you have a real support case, and the single most useful thing you can provide is the transaction hash or payment reference. A provider who watches their own wallet can find an unmatched transfer from that. A provider who can't will ask you to send a screenshot of your wallet, which is a much worse position to be in.
• You have several projects or keys → check which key your client is actually sending. Print the first and last four characters of the key your tool is using and compare it against the project you funded. Mismatched project balances take people days to find.
• Short requests succeed, long ones fail → the balance is real but small. Fund it, or shorten the request. This case is worth distinguishing because it usually gets misdiagnosed as rate limiting.
• The error appears only in one specific tool → the balance is fine and the tool is misconfigured. See the next section; 401 and "invalid API key" are a different family of problem and are covered separately.

If you're in the first line and funding is the blocker rather than a decision — that is, the payment method itself is the problem — the country-by-country payment write-ups are at How to pay for a DeepSeek API key in blocked countries, and there's a Pakistan-specific one at Paying for a DeepSeek API key from Pakistan.

"Invalid API key" is usually not a key problem

While you're here: a large share of what gets reported as a billing problem is actually a base URL problem, and the error messages actively mislead you about it.

• 401 Unauthorized — the key was rejected as unknown or malformed. If your key works in one tool and not another, the key is fine and the tool is wrong.
• 402 Insufficient Balance — the key was accepted; the account behind it can't pay. Your code is not the issue.
• 404 Not Found on a chat completion — almost always the base URL. If your SDK appends /v1/chat/completions itself and your base URL already ends in /v1, you'll get a path like /v1/v1/chat/completions.
• "Invalid API key" from an agent tool — check whether that tool wants the OpenAI-compatible base URL or the Anthropic one. Claude Code and the Anthropic SDK speak a different path and a different request shape from Cursor, Cline and the OpenAI SDK. A key that is perfectly valid will produce "invalid key" against the wrong one of the two.

The cheap way to separate all of these from a billing problem: send one request with curl or a ten-line script against the same base URL and key, outside your tool. If it succeeds, the account and key are fine and the tool's configuration is the problem. If it 402s, the account is the problem and no amount of tool configuration will fix it. That one test tells you which half of the problem you're in, and it takes about a minute.

Self-check 2: your top-up left, the balance didn't move

Run these in order. Each one is answerable without contacting anyone, and each one rules out a specific cause.

• Did the transfer actually confirm on-chain (or did the card actually settle)? A pending transaction is not a payment. This is the single most common cause and it resolves itself, usually within minutes.
• Was it sent on the network you were asked to use? USDT exists on TRON, BSC, Ethereum and others. A transfer on the wrong chain is not recoverable by the recipient, and it will never appear as a balance no matter how long you wait. Check the network before you check anything else.
• Is the amount, after fees, still above the stated minimum? Exchange withdrawal fees come out before the transfer lands. If the minimum is five dollars and the withdrawal costs sixty cents, you want to have sent more than five.
• Did you open a top-up order first, or just send to an address? Providers that match incoming transfers to open orders need an order to match against. A bare transfer to a deposit address can sit unmatched.
• Are you looking at the right account? Re-check the same project/key question from Self-check 1. Balances do not transfer between projects.
• Does the provider credit what actually arrives, or fail the order on a shortfall? If a small fee made your payment marginally short and the order failed rather than being credited, the money is usually recoverable — but only if you raise it, and only with the transaction hash.

If you've been through all six and the balance still hasn't moved, you're past self-service. Send the transaction hash with your order reference; that's the artifact that makes the problem findable.

Where we fit

We're NovaAPI. We are a reseller, not DeepSeek, and not an authorised partner. We hold no partnership and no reseller agreement. Payment options and the mechanics of each are at our payment help page.

The design decisions that matter for exactly the failures above, stated as mechanisms rather than promises:

Balance is credited for what actually arrives on-chain. If an exchange withdrawal deducts a fee on the way, the remainder is credited to your order rather than failing it. That's the deliberate answer to the fourth item in Self-check 2.

Top-up orders are created before you send. So an incoming transfer has something to match against, and an unmatched transfer is a findable problem rather than a lost one.

Your key is issued to you and revocable by you. Your balance sits on your own account, and you can spend it down and leave — no minimum monthly commitment and no auto-renew. That matters at the exact moment you're debugging a 402: you should be able to check your own balance without asking anyone.

One upstream vendor, no pooled accounts. Our supply is not a rotating cast of borrowed keys. We can't promise that no upstream will ever change anything, but the specific failure mode where a provider's access dies because the accounts it resold were terminated is not one our supply has.

We screen requests, and we say so. Every request goes through an automated moderation endpoint, and flagged requests leave an excerpt with us for 180 days. Requests that aren't flagged aren't stored as content. "We don't log your prompts" would not be true here, so we say the version that is. Practically: the same question applies to any third-party API, ours included: check where your prompts go, and pick one whose disclosure you can actually read.

If you hit 402 on our endpoint and your balance looks wrong, the transaction hash or your order reference is what we need. Setup for Claude Code, Cursor, Cline, Aider and the OpenAI SDK — including which base URL each one expects — is in the docs.