CoinAPI's Crypto Order Book Data: A Look at Tick-Level Information

A crypto price tells you where the market is trading. An order book tells you what is happening underneath that price.

Bids, asks, spreads, depth, individual orders, cancellations, fills, and liquidity changes all provide information that disappears when market activity is reduced to OHLCV candles or a last-traded price. For trading systems, market makers, quantitative researchers, and AI teams, that additional detail can matter.

CoinAPI provides cryptocurrency order book data across multiple levels of granularity, from best bid and ask quotes to aggregated market depth, individual orders where exchanges expose them, and raw Level 4 order lifecycle data for supported markets such as Hyperliquid.

Introduction to Order Books

A crypto order book represents the buy and sell liquidity currently available for a particular market.

On one side are bids: orders from market participants willing to buy.

On the other side are asks: orders from participants willing to sell.

The highest bid and lowest ask form the current top of the book. The difference between them is the bid-ask spread.

But an order book can reveal much more than the current spread.

It can show how much liquidity is available at different prices, how quickly that liquidity changes, how large an order could affect execution price, and how market participants add or remove orders as conditions change.

This makes order book data useful for:

• liquidity analysis
• spread monitoring
• slippage estimation
• market impact modeling
• algorithmic execution
• market making
• market microstructure research
• historical replay and backtesting
• AI and machine learning models

The amount of information available depends on the order book level.

Order Book Levels Explained: L1, L2, L3, and L4

The terms L1, L2, L3, and L4 describe progressively more detailed views of market activity.

They are related, but they are not interchangeable.

Level 1: Best Bid and Ask

Level 1 is the simplest view of an order book.

It contains the best bid and best ask, together with the amount available at each side.

For example:

From this information, you can immediately see that the spread is $5.

L1 is useful when you need to know the currently available market price without processing the entire depth of the order book.

Typical applications include:

• best bid/ask monitoring
• spread calculations
• market dashboards
• reference pricing
• basic execution monitoring

In CoinAPI, best bid and ask information is typically represented through quote data.

Level 2: Aggregated Market Depth

Level 2 goes beyond the best bid and ask.

It shows liquidity across multiple price levels.

For example:

The important distinction is that L2 aggregates liquidity by price level.

Suppose three separate orders are resting at $60,000:

• 0.5 BTC
• 1.0 BTC
• 1.5 BTC

An L2 order book may represent them as one price level:

$60,000 → 3.0 BTC

You can see how much liquidity exists at that price, but not necessarily which individual orders created it.

L2 is particularly useful for:

• analyzing market depth
• estimating slippage
• calculating order book imbalance
• measuring available liquidity
• modeling execution costs
• monitoring changes around the midpoint
• building trading and market-making systems

The amount of depth you receive also depends on the interface and source.

A feed may expose full available L2 depth, a limited number of levels, or snapshots of the book.

That distinction matters when choosing CoinAPI's delivery method.

Level 3: Individual Orders Where Available

Level 3, often called Market by Order, adds another layer.

Instead of showing only aggregated liquidity at each price, L3 can preserve the individual passive orders that make up the order book.

For example, L2 might show:

$60,000 → 3.0 BTC

L3 may reveal that the level consists of:

This makes it possible to study how individual orders enter, change, move through, or leave the book.

However, there is an important limitation:

CoinAPI supports L3 where the venue exposes market-by-order data.

L3 is not universally available across every cryptocurrency exchange or every market.

If the source exchange does not publish individual order identifiers, CoinAPI cannot manufacture true order-level information from aggregated depth.

Availability therefore depends on the exchange, market, symbol, and delivery method.

Where supported, Level 3 can be valuable for:

• queue-position analysis
• individual order lifecycle research
• advanced market making
• cancellation analysis
• execution modeling
• order-flow analysis
• liquidity behavior research
• market microstructure studies

Developers should confirm L3 availability for the exact venue and symbol they plan to use rather than assuming all markets expose order-level information.

Level 4: Exchange-Native Order Lifecycle Data

Level 4 goes beyond the traditional L1-L3 model.

Instead of representing only the resulting state of the order book, L4 can expose the exchange-native events and mutations that create that state.

This distinction is particularly relevant for Hyperliquid.

CoinAPI's Hyperliquid L4 feed captures raw, unaggregated order and trade mutations rather than waiting for blockchain blocks or reducing activity into conventional price-level updates.

Events can include activity such as:

• order placement
• order modification
• cancellation
• rejection
• partial fill
• execution

Additional Hyperliquid-specific information can include the order identifier, user address, order type, time-in-force, and order status.

This gives researchers visibility not just into what the order book looks like, but into how it got there.

That can be useful for advanced applications such as:

• order lifecycle reconstruction
• participant behavior analysis
• latency-sensitive research
• market microstructure modeling
• execution research
• liquidity-provider analysis
• high-frequency strategies
• machine learning using raw market events

CoinAPI currently delivers Hyperliquid L4 through dedicated WebSocket DS real-time feeds and historical Flat Files.

A normalized example symbol is:

HYPERLIQUIDL4_PERP_BTC_USDC

Why Order Book Data Is Important

Candles tell you what happened to price.

Order books provide information about the liquidity and market structure around that price.

Suppose BTC moves from $60,000 to $60,500.

An OHLCV candle can show the move.

It cannot tell you whether:

• sell-side liquidity disappeared before the move;
• the spread widened;
• buyers repeatedly consumed the ask;
• a large block of liquidity appeared or vanished;
• the book became heavily imbalanced;
• a large order would have experienced significant slippage.

Those details can be important when building strategies that interact directly with the market.

Liquidity

Order book depth helps show how much volume is available around the current price.

A market with substantial depth can generally absorb larger orders with less price impact than a thin market.

Spread

The bid-ask spread is one of the simplest measures of immediate trading cost.

Wider spreads can increase execution costs even when the underlying asset price has not changed substantially.

Slippage

The best ask does not tell you what price you will receive for an order that is larger than the liquidity available at that level.

L2 depth makes it possible to estimate how an order would move through multiple levels of the book.

Order Book Imbalance

Researchers can compare liquidity on the bid and ask sides of the book.

This information can be turned into indicators describing short-term supply and demand conditions.

Queue Dynamics

Where true L3 data is available, researchers can go deeper and analyze individual resting orders.

This can help model queue position, cancellations, order persistence, and execution probability.

Historical Replay

Tick-level historical data allows researchers to reconstruct previous market conditions rather than relying only on aggregated bars.

This can make execution-sensitive backtests considerably more realistic.

How CoinAPI Collects, Normalizes, and Delivers Order Book Data

Cryptocurrency exchanges do not expose market data in one universal format.

Each venue can have its own:

• symbol conventions
• message formats
• timestamps
• update logic
• sequence numbers
• order book depth
• API protocols
• market identifiers

A market might be identified natively as BTCUSDT, BTC-USD, XBT/USD, or something else entirely.

CoinAPI normalizes this information into consistent identifiers.

Examples include:

BINANCE_SPOT_BTC_USDT

COINBASE_SPOT_BTC_USD

HYPERLIQUIDL4_PERP_BTC_USDC

This allows applications to work with a consistent market-data model across hundreds of exchanges instead of building independent parsing and normalization logic for every venue.

CoinAPI currently provides cryptocurrency market data from 400+ integrated exchanges.

How you access the order book depends on what you are trying to build.

REST API: Current and Historical Order Book Snapshots

REST is useful when you want to request a market state at a particular point, rather than maintain a continuous streaming connection.

CoinAPI REST endpoints can provide current, latest, and historical order book information depending on the endpoint.

For Level 2 historical order books, an important limitation applies:

REST historical order book data consists of normalized L2 snapshots. It is not a complete tick-by-tick record of every order book event.

Historical REST snapshots are useful for applications such as:

• lightweight historical analysis
• periodic depth comparisons
• market research
• dashboards
• liquidity sampling

But they are not the right source if you need deterministic reconstruction of every historical change to the order book.

For full historical replay, use Flat Files.

CoinAPI also provides REST endpoints for current L3 order book snapshots where the underlying market supports L3 information.

WebSocket: Real-Time Order Book Streaming

WebSocket is designed for continuously changing real-time market data.

Instead of repeatedly requesting the current state, applications subscribe once and receive new updates as the market changes.

CoinAPI supports several L2 WebSocket data types.

book

Full L2 order book snapshots and real-time updates.

This is suited to applications that need to maintain a continuously updated local representation of market depth.

book5

Snapshots containing the five best bid and ask levels.

Useful when an application needs more information than L1 but wants to keep bandwidth and processing requirements relatively low.

book20

Snapshots containing the best 20 bid and ask levels.

This can be useful for trading dashboards, liquidity monitoring, and execution analytics.

book50

Snapshots containing the best 50 bid and ask levels.

It provides greater visible depth without necessarily processing the full order book.

Where L3 data is exposed by the venue, CoinAPI also supports real-time order-level L3 messages.

And for Hyperliquid L4, CoinAPI provides a dedicated WebSocket DS book_l4 stream containing order-by-order snapshots and updates with Hyperliquid-specific information.

FIX: Real-Time Market Data for Institutional Systems

CoinAPI also provides market data through FIX 4.4.

FIX is widely used across institutional trading infrastructure and provides an alternative to WebSocket for real-time market data delivery.

Applications can subscribe to:

• bids
• asks
• trades
• order book snapshots
• incremental order book updates

FIX is particularly relevant for trading firms and institutional systems that already operate FIX-based infrastructure and want CoinAPI market data to fit into existing workflows.

Flat Files: Full Historical Order Book Replay

For large-scale historical order book analysis, CoinAPI provides Full Limit Order Book Flat Files.

This is the appropriate delivery method when the goal is to reconstruct historical market state using the underlying order book update stream.

Full Limit Order Book data captures changes to the book so researchers can rebuild the market state through time.

This makes Flat Files suitable for:

• historical backtesting
• order book replay
• market microstructure research
• execution simulations
• slippage modeling
• liquidity research
• queue analysis
• large-scale quantitative research
• AI and machine learning datasets

Files are organized using normalized exchange and symbol identifiers.

For example:

BINANCE_SPOT_ETH_USDT

New Trades, Quotes, and Full Limit Order Book data published from June 9, 2026 uses hourly partitions such as:

D-YYYYMMDDHH

Legacy historical data published before that date remains available in daily partitions.

The important distinction is simple:

REST historical order books provide snapshots. Flat Files provide the historical update data needed for full-depth replay.

MCP Server: Order Book Data for AI Workflows

Market data is increasingly consumed not only by traditional applications, but by AI systems.

CoinAPI's Market Data MCP Server provides an MCP-compatible interface that AI clients and agentic applications can use to query CoinAPI data.

The server exposes tools for market data including:

• quotes
• trades
• order books
• OHLCV
• exchange rates
• metrics
• metadata

This can be useful when building AI workflows where a model needs structured access to market information without requiring every query to be manually translated into a REST integration.

For example, an AI research agent could discover a valid CoinAPI symbol, retrieve market information, compare liquidity snapshots, and combine the results with other analytical steps.

For large-scale model training or tick-level historical replay, Flat Files remain the more appropriate source.

MCP is better suited to interactive querying and AI-driven data workflows.

Real-Time vs Historical Order Book Data

There is another important distinction when working with CoinAPI:

real-time and historical data are optimized for different objectives.

Real-time data prioritizes latency

WebSocket and FIX feeds are designed to deliver market events as quickly as possible.

In a live environment, exchanges can produce:

• late messages
• out-of-order events
• duplicate events
• corrections
• connectivity gaps

Real-time pipelines minimize processing so applications can receive market changes with low latency.

Historical data prioritizes completeness

CoinAPI's T+1 historical pipeline is designed to create a canonical historical record.

After the UTC trading day closes, historical data can be reconciled for:

• late events
• out-of-order records
• duplicates
• exchange-side corrections

As a result, the final historical dataset may not bit-match the real-time feed captured during the trading session.

That is expected.

The two products solve different problems.

For a live trading engine, latency matters.

For research, backtesting, reconciliation, or reproducible analysis, the canonical historical record usually matters more.

This distinction is especially important when validating a historical simulation against previously captured real-time data.

Small differences do not necessarily indicate an error. They can be the result of historical reconciliation.

When Should You Use Each Level and Interface?

The best dataset is not always the most granular one.

It depends on the problem you are solving.

There is little benefit in processing billions of L3 or L4 events when your application needs only the current spread.

Likewise, L1 quotes are not enough when you are trying to model the execution of a large order across multiple levels of market depth.

Choose the level based on the question.

Order Book Data for Algorithmic Trading

Algorithmic trading systems can incorporate order book information into both trading signals and execution decisions.

Instead of reacting only to price, an algorithm can analyze:

• spread
• depth
• bid/ask imbalance
• liquidity concentration
• changes in available volume
• short-term order flow

This can help determine not only whether to trade, but also how to execute.

A strategy may decide to delay execution when liquidity is thin, split a large order across multiple levels, or change its execution logic when spreads widen.

Order Book Data for Market Making

Market makers need to continuously decide:

• where to place bids and asks;
• how large those orders should be;
• how inventory risk is changing;
• how much competing liquidity is available;
• whether orders are likely to execute.

L2 data provides the broader shape of the order book.

Where available, L3 can add individual order behavior and queue information.

L4 can go even further for supported venues by exposing the underlying order lifecycle events.

The appropriate level depends on the market structure and the sophistication of the strategy.

Order Book Data for Backtesting

Backtesting with OHLCV alone can produce unrealistic results for execution-sensitive strategies.

A candle might show:

• open: $60,000
• high: $60,500
• low: $59,900
• close: $60,400

But it does not show:

• what liquidity was actually available;
• what spread existed when a signal fired;
• whether a $500,000 order could have executed at the observed price;
• how deeply an order would have crossed the book;
• whether liquidity disappeared before execution.

Historical Full Limit Order Book data allows researchers to model these conditions much more realistically.

For strategies where execution quality materially affects returns, this can make the difference between a theoretical backtest and a usable market simulation.

Order Book Data for AI and Machine Learning

Order books are also valuable inputs for machine learning.

Instead of training models exclusively on price candles, researchers can create features describing the state and evolution of market liquidity.

Examples include:

• spread
• depth at different distances from the midpoint
• bid/ask imbalance
• liquidity concentration
• changes in depth
• cancellation activity
• order arrival rates
• queue behavior
• execution activity

L3 and L4 can provide even more detailed representations of order lifecycle behavior where those datasets are available.

Potential applications include:

• short-term price movement classification
• liquidity forecasting
• volatility modeling
• execution optimization
• anomaly detection
• market-regime classification
• market-making models

More granular data does not automatically produce a better model.

It increases the information available to the model—but also the volume, complexity, and risk of overfitting.

Data quality, realistic labeling, feature engineering, validation methodology, and execution assumptions remain critical.

From Price Data to Market Structure

There is a large difference between knowing the latest BTC price and understanding the market that produced it.

L1 shows the best bid and ask.

L2 shows aggregated liquidity across price levels.

L3 exposes individual orders when the underlying venue publishes market-by-order information.

L4 goes further for supported markets such as Hyperliquid by exposing raw order lifecycle events and exchange-native mutations.

CoinAPI provides these datasets through different interfaces depending on whether the goal is live monitoring, institutional trading, historical research, full-market replay, or AI-assisted analysis.

For lightweight analysis, a REST snapshot may be enough.

For live trading, WebSocket or FIX is a better fit.

For deterministic historical replay and backtesting, use Flat Files.

For AI applications that need interactive access to structured market data, use the Market Data MCP Server.

The key is not simply getting more data.

It is choosing the right level of market information for the problem you are trying to solve.

Explore CoinAPI Order Book Data, learn more about Level 3 Order Book Data, or explore Hyperliquid L4 Data.

Ready to work with real-time and historical crypto order book data? Get started with CoinAPI.