Learn / Exchange APIs

Binance testnet API keys

Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs before acting on a number.

Binance’s spot testnet is a separate hostname with separate credentials, which is the safe arrangement: testnet keys do not exist on production, so pointing at the wrong host fails with an authentication error rather than placing a real order.

PurposeURL
Testnet RESThttps://testnet.binance.vision/api/v3/
Testnet WebSocketwss://stream.testnet.binance.vision:9443
Production RESThttps://api.binance.com

Compare OKX, where demo trading shares the production hostname and is selected by a header. Binance’s version is harder to get wrong.

What stays the same

The request mechanics are identical, which is the point:

  • API key header: X-MBX-APIKEY
  • Signature algorithms: HMAC-SHA256 (case-insensitive signature), RSA with PKCS#8 keys (case-sensitive), Ed25519 (case-sensitive, documented as recommended for best performance)
  • Signed requests need timestamp; recvWindow is optional, defaults to 5000 ms, maximum 60000 ms
  • Error shape: {"code": -1121, "msg": "Invalid symbol."}
  • Status families: 4XX client error, 429 rate limit, 418 IP ban, 5XX server error

So the code you write against testnet is the code that runs against production. The base URL and the credentials are the delta.

What does not transfer

This is the part worth planning for, because each of these produces a first-day-live surprise.

Symbol availability. Testnet does not list everything production does. A symbol that works in testing can simply not exist live, and the failure is a BadSymbol rather than anything that hints at the environment.

Filters and minimums. Minimum order sizes and lot filters come from GET /api/v3/exchangeInfo per symbol, and they differ between environments and change on production without notice. An order size that passed in testing can be rejected live with -1013 INVALID_MESSAGE — “the request is rejected by the API” — because it failed a filter before reaching the matching engine.

Liquidity and fills. Testnet fills are optimistic. Slippage, partial fills and depth are not realistic. Anything you conclude about execution quality from testnet is not evidence.

Key permissions and their rules. Production keys carry the permission model testnet does not exercise — the 90-day expiry of spot trading permission on keys without an IP whitelist, the requirement that withdrawals need IP restriction, the enableFutures constraint for keys predating the futures account. None of this shows up in testing.

Rate limits in anger. Binance rate limiting is weight-based, not request-count-based — endpoints cost different amounts. Exceeding it returns -1003 TOO_MANY_REQUESTS, and severe violations escalate to an IP ban signalled by HTTP 418. Testnet traffic patterns rarely reproduce this.

A migration checklist

When moving from testnet to production:

  • Base URL changed, and logged at startup so the environment is visible in your logs rather than inferred
  • Production credentials in place, and testnet credentials removed from the environment entirely
  • Key permissions asserted at startup via GET /sapi/v1/account/apiRestrictions — expect enableReading true, enableWithdrawals false
  • IP whitelist applied, or the 90-day trading-permission expiry accepted knowingly
  • Symbols verified to exist on production
  • Order sizes checked against production exchangeInfo filters
  • Rate limit handling exercised — and order retries not automatic
  • First live orders sized small, because you have tested the software and not yourself

Getting testnet credentials

Testnet accounts are issued separately from your real Binance account — you sign in at the testnet site and generate keys there. Two practical consequences:

They are periodically reset. Testnet environments are maintenance environments, and balances and keys can be wiped. Do not build anything that assumes a testnet key is permanent, and do not be surprised when one stops working for no reason you caused.

Testnet balances are not funded from anywhere real. They arrive with the account. This is obvious in principle and occasionally confusing in practice when a balance changes without you trading.

The mistake worth engineering against

Not “testnet credentials in production” — that fails immediately and loudly, which is the arrangement working correctly.

The one to guard against is production credentials with the testnet base URL still configured, or the reverse in a code path you did not test. The fix is to derive both from a single environment setting rather than configuring them independently, so they cannot disagree:

BASE, KEY, SECRET = (
    ("https://testnet.binance.vision", TESTNET_KEY, TESTNET_SECRET)
    if ENV == "testnet"
    else ("https://api.binance.com", LIVE_KEY, LIVE_SECRET)
)
log.info("binance environment=%s base=%s", ENV, BASE)

One switch, two values, one log line. It removes the category of bug where the URL and the credentials were changed at different times.

FAQ

Do Binance testnet API keys work on the live API?

No. Testnet credentials exist only on testnet.binance.vision and production credentials only on api.binance.com. This is a safety feature — an environment mix-up produces an authentication error instead of a real trade.

Why does my order work on testnet but fail on production?

Most often a symbol or filter difference. Testnet does not list every production symbol, and minimum order sizes and lot filters differ and change without notice. A filter rejection typically surfaces as -1013, since the order never reaches the matching engine. Check GET /api/v3/exchangeInfo for the symbol on production.

Does testnet have the same rate limits?

The mechanism is the same — weight-based per endpoint, -1003 on exceed, HTTP 418 for an IP ban on severe violations — but testnet traffic rarely reproduces production pressure. Treat rate limit handling as untested until it has run live.

Is testnet useful if the fills are unrealistic?

Yes, for what it is for. It tests plumbing, parameters, error handling and your own workflow, which is where most mistakes live. It does not test execution quality, and conclusions about slippage or fill rates drawn from it are not evidence.