If you work with crypto market data long enough, you’ll eventually run into a strange situation.
Your backtest looks stable.
Your production system behaves differently.
Nothing in the strategy changed.
The difference is usually not the model. It’s the data aggregation that quietly removed information.
Order book data is a perfect example. Many teams begin with Level 2 (L2) snapshots because they are easy to store and simple to analyze. But snapshots are not the raw process of the market - they are an aggregated picture of it.
And when you’re looking for microstructure signals short-horizon patterns used by trading systems, quant researchers, and execution models, aggregation decides what you can and cannot observe.
This article breaks down:
• what L2 snapshots and incremental updates actually represent
• which microstructure signals get lost when you sample or aggregate
• when L2 snapshots are a practical choice
• when you should move to true L3 order-by-order data
• how to access both using CoinAPI’s Market Data API
What do L2 snapshots and incremental updates actually represent?
Understanding the difference between snapshots and updates is the first step in working with order book data correctly.
L2 snapshots
An L2 snapshot is a point-in-time image of the order book.
It shows price levels and the total size available at each level.
| Bid price | Bid size | Ask price | Ask size |
| 40,000 | 2.1 BTC | 40,010 | 1.4 BTC |
| 39,990 | 3.0 BTC | 40,020 | 2.2 BTC |
This type of data answers a simple question:
“What did the order book look like at time T?”
Snapshots are compact and easy to store, which is why they are commonly used in dashboards, analytics systems, and historical datasets.
But they hide the sequence of events that produced the book.
Incremental updates
Incremental updates (also called deltas) describe changes between states.
Instead of showing the whole book, they show what changed.
Examples:
• a price level appears
• the size at a level changes
• a level disappears
• a specific order is canceled or partially filled
These updates answer a different question:
“What happened between time T and time T+Δ?”
They preserve the sequence of events, which is critical for microstructure analysis.
The key difference
Two order books can look identical in a snapshot but have completely different histories. One may have been stable. Another may have experienced heavy cancellations and re-orders. Snapshots hide that difference. And for strategies that rely on behavior, that difference matters.
Which microstructure signals get lost when you sample or aggregate?
Aggregation does not simply compress data; it removes behavior.
Below are several signals that can disappear when order book data is sampled or aggregated.
1. Cancellation bursts and queue churn
One classic pattern in markets is liquidity that appears and disappears quickly.
Large orders may enter the book and vanish milliseconds later.
With snapshot sampling you may miss:
• rapid add-cancel cycles
• temporary liquidity walls
• moments when queue depth resets
If the entire event occurs between two snapshots, it cannot be reconstructed later.
2. Spoof-like behavior becomes harder to detect
Spoof-style patterns are defined by quick placement and cancellation of orders relative to price movement. Snapshots may show that a large level existed briefly, but they lose important context:
• the exact lifespan of the order
• its timing relative to trades
• whether it repeatedly appeared at different prices
This is why many “book pressure” signals perform well in backtests but fail live. Snapshots make liquidity appear more stable than it really is.
3. Spread flicker and fast liquidity replacement
The bid-ask spread can change very quickly during volatile periods.
Snapshots often underestimate:
• how often the spread widened
• how frequently best quotes were replaced
• how short-lived top-of-book liquidity actually was
For execution models, these details affect slippage estimates.
4. Price-level aggregation hides order intent
L2 books aggregate all orders at the same price level.
That means you lose information about individual orders.
For example:
| Scenario | What L2 shows | What actually happened |
| One large order | 100 BTC at $40,000 | single participant |
| Many small orders | 100 BTC at $40,000 | 100 traders each with 1 BTC |
These two cases look identical in L2 data… but their market behavior is completely different.
5. Timestamp mismatches can create phantom signals
Microstructure analysis depends heavily on timing.
CoinAPI provides two timestamps in market data:
| Field | Meaning |
| time_exchange | timestamp from the exchange |
| time_coinapi | time the event reached CoinAPI infrastructure |
When studying market behavior, use time_exchange.
When measuring pipeline latency, use time_coinapi.
Mixing them can accidentally create lead-lag signals that are not real.
When are L2 snapshots a practical choice?
Despite their limitations, L2 snapshots are extremely useful. Many systems do not require the full event stream of the order book.
Snapshots are usually sufficient for:
• liquidity dashboards
• depth visualization tools
• high-level market monitoring
• cross-exchange comparisons
• coarse slippage estimation
In these cases the simplicity and efficiency of snapshots outweigh the missing microstructure detail.
When should you move beyond snapshots?
Snapshots become risky when your research depends on order flow behavior rather than static depth.
You should consider incremental or L3 data when working on:
• market making strategies
• passive execution models
• liquidity shock detection
• queue position modeling
• manipulation detection
• machine learning features built from order flow intensity
If your model assumes liquidity persists until traded, snapshots quietly encode that assumption. Real markets behave differently.
L2 fallback vs true L3: how to choose the right data
A useful way to decide is to start with the question:
What behavior must your dataset capture?
Step 1 — Define what you need to observe
Ask yourself:
• Do I need to see the state of the book, or how the state changed?
• Do I need order identity or only price levels?
• Can I tolerate missing events between snapshots?
If behavior matters, snapshots are only a fallback.
Step 2 — Choose the appropriate data level
| Data type | What it shows | Typical use |
| L1 quotes | best bid and ask | top-of-book analysis |
| Trades | executed orders | tape and order flow |
| L2 book | aggregated depth | liquidity monitoring |
| L3 book | order-by-order events | queue and microstructure research |
| Tick updates | full event stream | historical replay |
The deeper the data level, the more behavioral information it preserves.
How to access L2 and L3 order books using CoinAPI
CoinAPI’s Market Data API provides several ways to work with order book data, depending on your use case.
Get the current L3 order book (order-by-order)
CoinAPI exposes true L3 order books via REST.
Documentation
https://docs.coinapi.io/market-data/rest-api/order-book-l3/current-order-book-by-symbol-id
Endpoint
Example request
Response includes:
• symbol_id
• time_exchange
• time_coinapi
• bids and asks
• order identifiers when available
These order IDs enable order-level analysis and queue behavior research.
Retrieve multiple L3 books in one request
For research workflows across many symbols:
Documentation
https://docs.coinapi.io/market-data/rest-api/order-book-l3/current-order-books
Endpoint
Useful parameters:
• filter_symbol_id — select multiple instruments
• limit_levels — control book depth
Use L2 snapshots for depth monitoring
For systems focused on liquidity monitoring or visualization, L2 snapshots remain efficient.
Example data shapes for L2 snapshots can be found here:
https://www.apibricks.io/products/market-data-api/data-samples
Snapshots provide a compact view of order book depth while avoiding the complexity of full event reconstruction.
Stream order book updates via WebSocket
Real-time systems usually rely on streaming updates.
A typical workflow:
- Receive an initial snapshot
- Apply updates as they arrive
- Detect missing events
- Re-synchronize with a new snapshot if needed
Example WebSocket message structure:
Combine order book data with trades
Order books describe available liquidity. Trades describe what actually executed.
Combining both datasets provides a clearer picture of market behavior.
Trade messages from CoinAPI include taker_side (BUY/SELL), which is often used for building order flow imbalance signals.
Implementation pattern: snapshot + updates
A robust order book pipeline typically follows this sequence:
- Initialize state from a snapshot
- Apply incremental updates in sequence
- Detect gaps in the event stream
- Reinitialize when gaps occur
- Periodically reconcile with fresh snapshots
Avoid common mistakes:
• treating snapshots as ground truth
• filling missing events with interpolation
• mixing timestamp types without a clear purpose
Why exchange feeds limit reconstruction accuracy
Even the best data provider cannot recover information that an exchange never published.
Some exchanges throttle order book updates (for example, publishing updates every 100ms).
That means the highest possible fidelity depends on:
• what the exchange emits
• how the provider normalizes and distributes it
The realistic goal is maximum available fidelity, not perfect reconstruction.
Quick checklist: choosing the right dataset
If your system needs this → use this dataset
• best bid/ask dynamics → quotes (L1)
• order flow and aggressor behavior → trades
• liquidity monitoring → L2 snapshots
• queue behavior and order intent → L3 order books
• realistic historical replay → tick-level order book updates
Final thoughts
L2 snapshots are a useful abstraction.
For many products they are the right balance between simplicity and information.
But if you are studying market microstructure, execution quality, or short-horizon behavior, snapshots can hide the very signals you are trying to measure.
A simple rule helps:
• Snapshots show the state of the market.
• Incremental updates and L3 data reveal the behavior that created that state.
Understanding the difference is the first step toward building reliable trading and research systems.
Explore CoinAPI Market Data
If you’re building fintech products, analytics tools, or AI workflows, the fastest way to avoid confusion is to build on structured APIs from the start.
CoinAPI gives you unified access to financial signals in machine-readable form so your systems can rely on the data instead of constantly cleaning it.
👉 Explore CoinAPI from API BRICKS and build on data that stays consistent as you scale.
