If you’re asking, “What’s the update frequency for order book snapshots over WebSocket?” you’re really asking the wrong question.
Markets don’t move on a schedule. They move when someone places, cancels, or matches an order.
Expecting a fixed update interval from a live order book is like asking how often traffic updates on Google Maps. There is no every-100ms promise. There’s just reality, streaming as it happens.
And that distinction matters a lot if you’re trading, backtesting, or building infrastructure on top of crypto market data.
This article explains how order book WebSocket update frequency actually works, why websocket updates are event-driven, and how to think about real-time market data correctly.
Let’s break it down clearly.
Short answer (the one you actually need)
There is no fixed update frequency for order book snapshots via WebSocket.
Here’s how it really works:
- You receive one full L2 snapshot immediately after subscribing.
- After that, you receive incremental updates (deltas) the moment they occur on the exchange.
- The message rate is entirely event-driven and varies with market activity.
Quiet market? Fewer messages.
Volatile market? Bursts of updates, sometimes many per millisecond.
That’s not a limitation. That’s correctness.
Why “snapshot frequency” is the wrong mental model
A lot of developers come from REST-based polling or candle-based data. That trains you to think in intervals:
- every 1 second
- every 100 ms
- every minute
Order books don’t work that way.
An order book is a living structure. It only changes when something happens:
- an order is added
- volume is reduced
- an order is matched
- a level disappears
WebSocket streams reflect that exact behavior.
No changes → no messages.
Many changes → many messages.
Trying to impose a fixed frequency upstream would actually destroy information.
What you actually get over WebSocket
When you subscribe to order book data via CoinAPI WebSocket:
- Initial snapshot You receive a full L2 snapshot so you can build the book locally.
- Incremental updates After that, you get real-time deltas:
- ADD
- SUB
- MATCH
- SET
- DELETE
Each message represents a real market event, not a timed refresh.
That’s why two users subscribed to the same symbol may see different message counts minute to minute. The market decides, not the API.
“But I need snapshots every X milliseconds”
Totally fair. And also your responsibility.
If your system needs periodic snapshots (for example, every 100 ms or every second), the correct approach is:
- apply deltas locally
- maintain the order book state
- emit your own snapshots on your chosen cadence
This gives you control without losing fidelity.
Think of WebSocket as the raw feed. Sampling is a downstream concern.
A simple example
Let’s say you subscribe to BTC-USDT on a liquid exchange.
In one second, you might see:
- 0 updates during a quiet moment
- 5 updates when a few orders move
- 200+ updates during a volatility spike
All of that is expected behavior.
If instead you forced “one snapshot per second,” you’d miss:
- transient liquidity
- microstructure shifts
- order queue dynamics
That’s the stuff real strategies live on.
What about historical snapshots?
This is where people often get confused.
Live WebSocket streams and historical order books are not the same pipeline.
- WebSocket: real-time, event-driven, exchange-native behavior
- REST historical order books: T+1, normalized, depth-limited snapshots
Historical snapshots are designed for analysis and reproducibility, not bit-for-bit replay of the live stream.
So if you compare:
- a live WebSocket book at 12:00:01
- a REST historical snapshot labeled 12:00
They will not match exactly. And they’re not supposed to.
Different purpose. Different guarantees.
Where CoinAPI fits in
CoinAPI doesn’t smooth, batch, or resample live order book data to make it feel predictable.
Instead, it gives you:
- immediate full snapshots on subscribe
- true event-driven deltas as the market changes
- normalized schemas across exchanges
- REST historical order books for next-day analysis
- flat files for full-depth reconstruction at scale
You get raw truth first. Structure second. Control always.
“We need ≤100 ms updates” - what that really means for order books
This is a very common requirement, and it’s usually framed the wrong way.
There is no configurable ≤100 ms update interval for live order book snapshots over WebSocket, and that’s by design.
Order book updates are event-driven, not clock-driven.
What CoinAPI actually delivers
- One full L2 snapshot immediately on subscription
- Then incremental updates pushed instantly whenever the exchange publishes a change
- If 10 updates happen in 10 ms → you receive 10 messages
- If nothing happens for 200 ms → you receive nothing
So in active markets, you’ll often receive updates far faster than 100 ms. In quiet markets, there may simply be no updates to send.
This is the fastest and most accurate possible model for live market data.
If you need a strict ≤100 ms cadence
If your system requires snapshots every 100 ms (for UI refreshes, model sampling, or downstream normalization), the correct approach is:
- Subscribe to the WebSocket order book
- Build and maintain the book locally using deltas
- Emit your own snapshots every 100 ms (or 50 ms, or 10 ms)
This gives you:
- deterministic timing
- no loss of microstructure detail
- full control over downstream behavior
Trying to enforce a fixed interval at the data provider level would drop information and introduce artificial latency.
Important clarification for latency-sensitive teams
≤100 ms update frequency is often confused with websocket latency, but they describe two very different things.
≤100 ms update frequency is not the same thing as ≤100 ms latency.
CoinAPI’s WebSocket streams are designed to:
- forward exchange updates immediately
- avoid batching or throttling
- preserve event ordering
In liquid markets, the effective update rate is often much faster than 100 ms, bursts of messages can arrive within a few milliseconds.
Final takeaway
Live markets don’t tick on a schedule.
They react.
WebSocket order book data reflects that reality exactly as it happens, without artificial pacing.
If you want fixed intervals, sample downstream.
If you want truth, stay event-driven.
Explore CoinAPI’s Market Data APIs to see how real-time WebSocket order books, historical snapshots, and full-depth data fit together, without stitching dozens of exchange integrations by hand.
