Testnet or Demo Mode: Where Your Order Actually Lands

Two sandboxes, two questions

A sandbox exists so that a mistake costs nothing. Once a venue offers two of them, the mistake to avoid changes: it is no longer trading with the wrong money, it is running the wrong test in the wrong place and drawing a conclusion that does not transfer.

Binance documents both environments side by side, and the comparison is the clearest statement of the split anywhere in its API reference:

Read down that table and a division of labour appears. Testnet is for integrating with what is not live yet; Demo Mode is for rehearsing against something shaped like the live market. Any test whose result depends on market realism belongs in the second column. Any test that depends on an unreleased feature belongs in the first.

Testnet: reset monthly, keys preserved

The Spot Test Network runs on its own hosts. REST is https://testnet.binance.vision/api, the WebSocket API is wss://ws-api.testnet.binance.vision/ws-api/v3, raw streams are on wss://stream.testnet.binance.vision, and the FIX gateways have testnet in the hostname. API keys are generated on the testnet website, not on the production site.

Two properties of the environment change how a test suite has to be written.

The reset. Binance states that the network is periodically reset to a blank state, including all pending and executed orders, and that every user receives a fresh allowance of assets at that point. The resets happen approximately once a month, and there is no prior notification. API keys are the exception: since August 2020 they survive resets, so a key created in January still authenticates in December while everything the key ever did is gone.

The consequence is that any test which reads history — yesterday’s fills, an open order placed by an earlier step, a balance accumulated by a previous run — is testing something that may have been deleted. The fix is to make tests seed their own state: fund from the faucet allowance at the start, place the orders the test needs, assert, and never assume the account carries anything forward.

The prices. Testnet’s prices and order books are independent of the live exchange. This is not a disclaimer about quality; it is a statement that the market being simulated is a different market. A strategy calibrated on testnet spreads learns the testnet’s spreads, which are a property of a thin synthetic book rather than of the instrument.

The funds are virtual. Binance is explicit: the balances are not real assets, can be used only on the Spot Test Network, and cannot be transferred in or out. There is no path by which a testnet balance becomes a real one, which is the point, and also why testnet cannot answer any question about deposits or withdrawals.

Demo Mode: same features, similar prices

Demo Mode is reached through the main Binance account — log in, open Demo Trading, and create an API key from the demo site’s key management page. The endpoints move to https://demo-api.binance.com/api, wss://demo-ws-api.binance.com, wss://demo-stream.binance.com and demo-fix-* gateways. The pattern is consistent: the same API, a host with a different prefix.

Three properties make it the better place for behavioural tests.

• The feature set is the live one. Binance says Demo Mode always has the same features as the live exchange, whereas Testnet sometimes runs ahead of it.
• The limits are the live ones. IP limits, unfilled order count and exchange filters are documented as exactly the same — the strongest wording in the comparison table, and the reason a rate-limit or rejection test is only meaningful here.
• The reset is under your control. You can reset your balance from the UI whenever you want, so a test can start from a known state without waiting for the calendar.

The prices are described as similar to live, and Binance attaches a warning that is worth quoting because it is the sentence most sandbox write-ups omit: realistic market data is not the same as real market data, and strategies that work in Demo Mode should not be assumed to work on the live exchange.

There is also an operational state that neither environment removes. During Demo Mode maintenance, Binance announces the downtime on the CHANGELOG beforehand, and during it you cannot place or cancel orders. A bot that treats a rejected cancel as a transient error and retries will hammer a maintenance window; a bot that surfaces the error will stop.

OKX: the switch is a header

OKX’s demo environment is the useful counter-example because the switch is not in the URL.

The REST base for Demo Trading is https://openapi.okx.com — the same value production uses. What makes a request a demo request is the header x-simulated-trading: 1. The WebSocket endpoints do differ (wss://wspap.okx.com/ws/v5/public, and the private and business equivalents), so half the client is host-selected and half is header-selected.

Three documented details complete the picture:

• Coverage. The API works in Demo Trading, but some functions are not supported: withdraw, deposit, purchase and redemption are named. A demo test that includes a funding or withdrawal step is testing something the environment does not implement.
• Key lifecycle. API keys that are not linked to an IP and carry trade or withdraw permissions expire after 14 days of inactivity — with the explicit exception that demo trading keys do not expire. Two environments, two expiry policies.
• Order caps. The demo environment documents a maximum of 4,000 pending orders, with 500 per trading symbol. Those are the numbers a stress test will hit, and they are published rather than discovered.

The design has one consequence that a Binance-shaped mental model misses. When the environment lives in a header, forgetting the header does not produce an error — it produces a production request with production credentials. The dangerous direction is not “demo order rejected”; it is “demo-looking code path placed a real order because one line of configuration was missing”.

Designing so the switch cannot fail silently

Configuration that selects an environment by host is self-evidencing: the URL is in the log line, the DNS name is wrong or it is right, and a misconfiguration fails against a host that does not exist for the credential. A header has no such property, so the guard has to be built.

1. Print the resolved environment at boot. The base URL and, where applicable, the header name and value, logged once per process. A single line answers the question that otherwise takes an hour.
2. Refuse mismatched credentials. A demo key presented to a production host should fail before the request is signed; so should a production key presented to a demo host. This is a check in the client, not a convention in the config file.
3. Assert the environment with a read before the first write. Query something whose response differs between environments, and abort if it does not match expectation. One extra request per process buys the assurance that the first order is where it was meant to be.
4. Seed state rather than inherit it. Monthly resets, on-demand resets and virtual funds all mean the account starts each run in an unknown condition unless the run puts it in a known one.
5. Match the test to the environment. Feature integration on Testnet, market behaviour and limit behaviour in Demo Mode. A rate-limit test on Testnet is a test of a generally similar limit; the same test in Demo Mode is a test of the actual one.
6. Keep keys separate by environment, and never reuse a production key in a sandbox. The isolation habits in sub-accounts and API key isolation apply with more force here, because a sandbox key is exactly the one that ends up in a repository.

The last item is where this connects to the rest of the API surface. Rate limits and order counts behave differently by environment and are explained in exchange API rate limits and order weights; the filters that reject an order are the same filter definitions the live venue applies, covered in why an exchange rejects your order. If the thing being tested is a depth consumer, the stream mechanics in building a local order book from Binance depth streams do not change between environments — but the book you build from testnet data is the testnet’s book, not the market’s.

What each environment can and cannot tell you

The table is short on purpose. Neither environment can answer the question most people bring to a sandbox — whether a strategy makes money — and both can answer the question that actually costs money when it is wrong: whether the client does what it was written to do.

Risk note. Endpoints, reset rules, limit wording, header requirements and unsupported functions in this article were read from Binance’s Spot API documentation and OKX’s API documentation on 2026-10-30. Sandbox behaviour changes; the distinction between a preview environment and a rehearsal environment does not. Nothing here is investment advice.