Order Book Reconstruction: What Can Go Wrong?

One missing order book update can change an entire backtest.

A trading strategy might appear profitable because it executed against liquidity that wasn't actually there.

The code works, the results look reasonable, but the historical market state is wrong…

That's the challenge with historical order book reconstruction. It's not enough to collect market data. You need to rebuild what happened, in the correct order, without silently introducing errors.

So how does it work, and how can you tell whether your historical order book data is reliable?

1. What Is Historical Order Book Reconstruction?

An order book shows the buy and sell orders available at different prices. But because traders constantly add, modify, and cancel orders, that picture changes continuously.

To reconstruct a historical order book, you typically need two things:

• A snapshot: The order book's state at a specific moment.
• Incremental updates: The changes that occur after that snapshot.

Apply those updates in the correct sequence, and you can recreate how the book evolved over time.

Consider a simplified BTC market:

Now remove the second event from your historical data.

Your reconstruction still shows an ask at $100.01 when the new bid arrives at that price. Suddenly, your historical market looks different from what actually happened.

This matters particularly for backtesting strategies that depend on spreads, liquidity, and execution prices.

L2 vs. L3 data: Level 2 represents aggregated liquidity at each price level, while Level 3 tracks individual orders when available. Both can support historical reconstruction, but L3 provides more detail for studying order behavior and queue dynamics.

2. Why Missing Updates Can Ruin a Backtest

Historical market data isn't always a perfect record of every event.

Exchange connections can drop. Collection systems can restart. Files can be incomplete, and snapshots can be applied incorrectly.

The problem is that an order book depends on everything that happened before it.

Imagine a trading algorithm designed to buy when strong liquidity appears on the bid side.

If your historical data misses several cancellation updates, the reconstructed book might show substantial buying interest that had already disappeared.

The algorithm sees a buying opportunity. In reality, that opportunity never existed.

The same issue affects execution simulation. A strategy might appear to fill orders at favorable prices simply because the reconstructed book contains liquidity that should have been removed.

A convincing backtest doesn't necessarily mean the underlying market data is accurate.

And not every reconstruction error is obvious. Some produce crossed books or invalid quantities. Others leave the data looking perfectly reasonable.

That's why checking for missing updates and inconsistent book states is an essential part of historical market research.

3. Why Timestamps Alone Aren't Enough

When reconstructing an order book, the natural assumption is that you can simply sort updates by timestamp.

Unfortunately, it's not always that straightforward.

Historical market data can contain multiple timestamps describing different stages of an event.

For example, CoinAPI provides:

• time_exchange — when the event occurred according to the exchange, or an estimated exchange timestamp.
• time_coinapi — when CoinAPI first received the update.

These timestamps serve different purposes.

Exchange time is useful for studying market activity and aligning events. Receive time helps researchers understand when information reached the data collection infrastructure.

But there's another complication.

Two updates can have exactly the same timestamp.

Suppose one update sets the quantity at a price level to 2 BTC, while another removes that level entirely.

If you apply the removal last, the level disappears. Reverse the updates, and the level remains.

Both versions can have identical timestamps, yet they produce different order books.

This is why accurate reconstruction requires a reliable event-ordering method, not just chronological sorting. Where timestamps are identical, developers need to understand the feed's sequencing rules rather than assume the timestamp alone resolves the order.

For CoinAPI's LIMITBOOK_FULL dataset, the exact tie-breaking behavior should be confirmed against the applicable dataset or venue rules before relying on it.

4. How to Validate Historical Order Book Data

Before using historical order book data in a trading model, it's worth checking whether the dataset can support the reconstruction you need.

For example, when analyzing Bybit BTC/USDT perpetual markets, you should first verify that you're using the correct instrument, not a similarly named spot market.

Then check the data itself.

Pay particular attention to gaps, reconnects, and unexpected resets.

A reconstructed book that becomes crossed or contains impossible quantities deserves investigation. However, a book that looks normal isn't automatically complete.

Some missing updates leave no obvious signs.

The purpose of validation isn't just to catch broken data. It's to understand how much confidence you can place in your research results.

For more complex strategies, exchange-native sequence information or independent snapshots may also be necessary to establish reconstruction accuracy.

5. How CoinAPI Helps with Historical Order Book Reconstruction

Building your own historical order book archive means collecting exchange data continuously, handling connection interruptions, managing storage, and maintaining the infrastructure over time.

CoinAPI offers another approach.

With CoinAPI Flat Files, developers can access historical order book snapshots and updates without operating their own long-term collection systems.

The LIMITBOOK_FULL dataset provides historical book changes for supported markets, including Bybit perpetuals, with L2 or L3 detail depending on exchange availability.

This allows researchers to spend less time building data collection infrastructure and more time studying market behavior.

Historical order book data can support research into liquidity changes, bid-ask spreads, order book imbalance, and how market depth behaves during volatile periods.

It can also support execution and slippage modeling, within the limitations of the available order book detail.

Developers can explore CoinAPI's Full Limit Order Book documentation and historical data samples to evaluate the dataset and test their reconstruction workflow.

FAQ

Can you reconstruct an order book using L2 data?

Yes. L2 snapshots and updates allow developers to reconstruct aggregated liquidity at different price levels, provided the data is sufficiently complete and correctly sequenced. Individual order positions require additional information.

What happens when an order book update is missing?

The reconstructed book may no longer reflect the actual market. The error can persist until a valid snapshot or resynchronization restores the correct state.

Is historical order book data different from OHLCV data?

Yes. OHLCV summarizes price and trading volume over time intervals. Historical order book data captures changes in available liquidity, offering more detail about market structure and trading conditions.

Reconstruct Historical Order Books with CoinAPI

Reconstructing historical order books shouldn't mean spending months building and maintaining your own data collection infrastructure.

With CoinAPI Flat Files, you can access historical order book snapshots and updates from supported crypto exchanges, including Bybit, and focus on what matters: analyzing liquidity, testing trading strategies, and understanding how markets behave.

Explore the LIMITBOOK_FULL dataset and start with sample data to see how it fits your research.

👉 Get Your API Key and Start with Free Credits

Related Topics

• Best API Tools for Crypto Traders
• How to Reconstruct Hyperliquid L4 Order Books Correctly
• Crypto Order Book Replay: A Complete Guide to Tick-Level Market Data
• Is CoinAPI historical data truly tick-by-tick or aggregated?
• Crypto Exchange Data API: Exchange-Level Market Data Explained
• Crypto Historical Data API: What Backtests Need That Live Price APIs Usually Miss