Binance Depth Streams and Snapshots: Building a Local Order Book

A depth stream is a delta, not a book

The first thing to internalise about btcusdt@depth is what it does not contain. Each event carries a symbol, an event time, a first update id U, a final update id u, and two short lists: bid price levels that changed and ask price levels that changed. It does not contain the rest of the book.

That leaves the builder with one job: hold a complete book and apply every change in order, with no gaps. The snapshot provides the starting state and the stream provides the changes. Everything difficult about the problem lives in the seam between the two, which is why Binance publishes an explicit procedure rather than describing it as an implementation detail.

There are two depth streams with different jobs:

• Partial book depth returns the top 5, 10 or 20 levels per side, complete on every message, at 1,000 ms or 100 ms. It is easy to consume and it is not a book. You cannot compute depth at a price band wider than 20 levels, and you cannot tell whether a level was added or simply moved into the visible window.
• Diff depth returns only the changes, at 1,000 ms or 100 ms, and needs a snapshot to initialise.

The name of the second stream is the whole problem statement. A diff is meaningless without the thing it is a diff against.

The seven steps, and why they are in that order

Binance’s documented procedure for managing a local book is short enough to quote in structure:

1. Open the diff depth stream.
2. Buffer the events received, and note the U of the first one.
3. Fetch a depth snapshot from the REST endpoint.
4. If the snapshot’s lastUpdateId is strictly less than the U from step 2, fetch the snapshot again.
5. Discard buffered events whose u is less than or equal to the snapshot’s lastUpdateId, then set the book to the snapshot.
6. Apply the remaining buffered events, then every subsequent event, using the update procedure.
7. On each event, check u against the local id; if U is greater than the local id plus one, discard the book and start again.

The order matters. Subscribing before snapshotting is what makes the buffer contain the events that will arrive during the snapshot request — a request that can take a round trip or more. If you snapshot first and subscribe afterwards, every change that happened in between is lost, and the book is wrong from its first millisecond without any error being raised.

The check in step 4 is the part most implementations skip. If the snapshot is older than the first buffered event, there is a hole between them and retrying is the correct response. Retry loops should be bounded, and each attempt costs weight.

The update procedure itself has three branches that map to three real states:

The gaps the stream cannot close

The gap test only catches a missing event. It does not catch a book that has stopped changing.

Consider a connection where the exchange stops publishing updates for one symbol — a matching-engine issue, a symbol suspension, a network path that silently drops the socket without a close frame. Your local id stops advancing. Every new event either matches the id or is a gap, and a silent empty stream produces neither. The book remains “valid” and goes stale.

Two habits address this. The first is to compare the event time E in each message against wall-clock time and alarm when the difference exceeds a threshold you choose. The second is to schedule an independent resync at a fixed interval — every few minutes during trading, or before any decision that depends on deep levels — rather than trusting the sequence to prove freshness.

The weight budget decides how often that is affordable. A single 5,000-level snapshot costs 250 request weight, and Binance’s public exchange information reports a request-weight ceiling of 6,000 per minute shared by every request the key makes. Twenty-four full snapshots a minute would consume the entire budget for the whole account; a 1,000-level snapshot costs 50, which allows 120 resyncs a minute in theory and a far smaller number in practice once every other endpoint is counted. Most book builders do not need the deepest snapshot at all — they need the levels they quote against.

Connection rules that decide uptime

The stream has hard limits, and each of them produces a failure mode that looks like an exchange problem:

• A connection is valid for 24 hours, and a serverShutdown event precedes the disconnection. Reconnect on the clock, not only on errors.
• The server sends a ping every 20 seconds and disconnects a connection that does not return a pong within a minute. The pong must echo the ping payload.
• Inbound messages are limited to 5 per second, counting pings, pongs and JSON control frames. A reconnect storm or an aggressive subscribe loop can trip this, and Binance states that repeatedly disconnected IPs may be banned.
• There is a limit of 300 connections per attempt every 5 minutes per IP, which is the rule that punishes a naive reconnect-on-failure loop most directly.
• wss://data-stream.binance.vision carries market data only. It is the right host for a public book builder and the wrong one for account events.

A book service that reconnects on a randomised delay, resubscribes once per connection, and rebuilds from a snapshot is a few dozen lines longer than one that reconnects immediately. The difference is measured in bans.

What the local book still cannot tell you

Even a perfectly synced book is not the exchange’s full state.

The snapshot and the stream both publish aggregated price levels, and a diff shows the new total at a level. It does not show how many orders sit there, how they are sized, or whether any of them belong to a hidden order type that never appears in the book at all — an iceberg’s reserve, or a venue-specific retail improvement order withheld from the public feed. Those orders still compete with yours when price arrives; they are simply invisible until they trade.

That asymmetry is not a data-quality problem to be engineered away. It is the reason a local book is a good input for quoting and a bad input for asserting what will fill. The related question of what depth actually predicts, and where the number stops being useful, is covered in spread, depth and slippage and in the comparison of how venues publish their order book snapshots. The imbalance-versus-last-price distinction is a separate trap, set out in whether book imbalance predicts the next print.

The other trap is the budget itself. Depth requests compete with order requests for the same weight ceiling, and a resync storm at the wrong moment can leave an account unable to place an order. The accounting is documented in API rate limits and order weights, and it is the reason a production book builder should reserve headroom rather than treat 6,000 as a target.

Risk note. The stream names, endpoints, limits and weight values in this article were read from Binance’s own Spot API documentation on 2026-10-30. Endpoints, weight schedules and limits change; the procedure is the durable part, the numbers are not. Nothing here is investment advice.