November 19, 2025

Is Level 3 Data Available in Crypto and What Can You Do With It

featured image

Level 3 market data exists in crypto only for a limited set of venues because most exchanges do not publish full order by order feeds. Teams that require queue position, order level state or detailed order flow can work with true L3 when a venue supports it or with fully reconstructed L3 when the raw events allow precise replay. Only a few spot venues publish true Level 3. Public comments across the community often mention Coinbase and Bitfinex because these venues expose order identifiers and per order updates. Most other venues publish Level 2 only.

L3 data is essential for high-frequency trading, order flow modeling, latency-sensitive strategy development, and regulatory research. L3 is only available for selected exchanges: BITSO and COINBASE.

Level 3 is the most granular form of order book data. Every order is tracked individually with its own identifier, size, price, direction and lifecycle event. An L3 feed shows the following for every update.

order_id

entry_px

entry_sx

is_buy

update_type

The order_id field is present only when the data stream or file contains Level 3. This matches the schema of the Full Limit Order Book data in the Flat Files system and appears directly in the order book files as a unique identifier for each individual order entry.

Level 3 allows researchers and engineers to see the actual behaviour of the matching engine rather than aggregated volume at a price.

Further reading:

  • Level 1 vs Level 2 vs Level 3 market data: How to read the crypto order book

Most traders never see true order by order feeds. Many exchanges do not publish Level 3. Conversations in public forums often show confusion between candles, Level 2 books and MBO updates. This creates the belief that Level 3 does not exist in crypto. In practice, only a few venues publish true L3 while most publish aggregated L2.

Only a few exchange APIs expose full order by order data. Most crypto venues publish aggregated Level 2 data where orders at the same price are merged. This limits visibility of queue position.

Typical venues that support true or partial L3 include spot venues that expose individual order identifiers such as Bitfinex, Coinbase Spot and some regional Binance streams. Many futures, perps and options venues publish aggregated L2 only because their engines do not expose per order events.

This is why most quants and machine learning teams must rely on vendors that collect, normalize and store every message in a reproducible way.

There are four recurring problems.

L3 event load is extremely high

A liquid pair such as BTC USDT can produce millions of individual order events in a single day. This overwhelms client ingestion pipelines when collected directly.

Exchanges use inconsistent schemas

One venue uses integer identifiers. Another uses string identifiers. Others reuse order identifiers or omit the order id field entirely. Matching and merging these differences adds engineering overhead.

Timestamps vary between venues

time_exchange and time_coinapi fields often diverge because each exchange reports timestamps with different precision or latency. The Flat Files documentation confirms that CoinAPI stores both timestamps with high precision and that each event is saved in the exact order received.

Gaps appear during downtime

When an exchange API stalls, client systems miss part of the order flow. Gaps make L3 backtests unreliable unless multiple ingestion points or recovery methods exist.

These issues block accurate order state reconstruction which limits strategy performance.

Further reading:

  • Why Not Just Use Exchange APIs Directly? The Hidden Cost of DIY Integration
  • Crypto Trading Latency FAQ: 10 Speed Questions Answered

Across thousands of customer interviews the same patterns appear.

Backtests fail due to inconsistent ordering

When a venue reports timestamps with low precision, event ordering can flip. This makes queue simulation unstable.

HFT systems fall behind during bursts

Real time L3 feeds are heavy. Sudden volatility spikes can produce bursts that exceed a custom engine’s capacity.

ML training requires complete history

Reinforcement learning teams and order flow modelling teams need multi year datasets with no gaps. Missing a single hour of L3 alters model behaviour.

Manual ingestion multiplies engineering cost

Teams often maintain bespoke connectors for each venue. Every API change or rate limit change requires maintenance.

These problems often push teams to rely on vendors that normalize and store L3 at scale.

Level 2 aggregates volume by price. Level 3 tracks every individual order with its own identifier. Level 2 shows how much volume sits at a price level. Level 3 shows which specific orders create that volume and how they change.

→ Readers who want a full technical comparison of all depth levels can review the detailed guide on how to read Level 1, Level 2 and Level 3 market data at https://www.coinapi.io/blog/level-1-vs-level-2-vs-level-3-market-data-how-to-read-the-crypto-order-book

Only a limited number of spot venues publish full order by order feeds. Many exchanges offer aggregated Level 2 books only. True L3 requires events that include order identifiers and precise lifecycle updates. CoinAPI provides Level 3 data from Bitso and Coinbase which are among the few venues that expose full per order updates.

Most derivatives venues publish L2 only. Their matching engines usually do not expose per order identifiers which makes true L3 unavailable for perps and futures.

Reconstruction is possible when the venue reports granular incremental changes with enough detail to recreate the sequence of events. If order identifiers are missing, full reconstruction cannot be performed.

Level 3 updates describe every individual order event. Each message contains event metadata such as event_type, sequence and timestamps from the exchange and the capture system. Instrument identifiers include exchange_id and symbol_id. Order level fields include order_id, side, price, quantity and remaining_quantity after the update. When the event represents a match, additional fields appear such as maker_order_id, taker_order_id, aggressor_side, last_price and last_size. Some venues expose optional attributes such as order_type, time_in_force or post_only flags. These fields allow full reconstruction of the order book at the per order level and match the structure used in the Full Limit Order Book specification in the Flat Files system.

A single day for a liquid pair such as BTC USDT can range from several gigabytes to more than ten gigabytes of Level 3 events. Size depends on volatility, the number of active participants and the rate of order updates. Very active major pairs often produce three to ten gigabytes when compressed and much larger files when uncompressed. Mid liquidity majors usually fall below three gigabytes and quieter markets often remain below one gigabyte. These differences come from event volume, average message size and compression effects. For full depth L3 history, use the T plus one Flat Files where each file reflects a complete reconciled record for the day.

Level 3 is not too heavy for real time trading when the subscription is narrow and the system is built for high throughput. Market making engines and microstructure models use Level 3 in production every day. Event rates for very active symbols range from hundreds to a few thousand updates per second, and compressed bandwidth remains in the range of tens of kilobytes per second. Level 3 becomes heavy only when too many venues or symbols are subscribed at once or when full book state is rebuilt unnecessarily. Focused subscriptions and efficient event processing keep real time performance stable.

Yes. Level 3 can be downloaded in bulk through CoinAPI Flat Files. The T plus one pipeline provides full depth per order history with deduplication and late event reconciliation. Files are delivered through an S3 compatible interface and are partitioned by day and by market, which makes multi year research straightforward. Very active symbols often produce several gigabytes per day when compressed, mid liquidity symbols usually fall below three gigabytes, and quieter markets remain below one gigabyte. These ranges depend on volatility and event volume.

Access requires an API key with Flat Files entitlement. Any S3 client can list and sync the venue, symbol and date prefixes needed for long horizon analysis. This format provides the canonical historical record and is preferred for research because real time streams are latency optimized and will not match the reconciled next day output. Historical REST snapshots represent L2 depth only, so full depth L3 history is available through Flat Files.

Yes. Both timestamps are stored. time_exchange reflects the timestamp from the venue. time_coinapi reflects the precise moment the event was captured. Using both fields allows deterministic reconstruction of order flow.

Out of order events can occur in real time because venues and network paths do not always deliver updates in perfect sequence. Real time streams preserve exchange order as closely as possible, but they use minimal processing to keep latency low. Small sequencing issues are normal and can be corrected locally by using sequence identifiers or exchange_time when the venue provides them. A short reorder buffer and basic gap detection usually keeps the book consistent.

The next day T plus one pipeline resolves this fully. Late or out of sequence events are reconciled, deduplicated and sorted into the final canonical record. This historical output is the preferred source for research and backtesting because it reflects the complete and corrected event sequence rather than the live latency-optimized stream.

To see the full Level 3 schema and access instructions, visit the CoinAPI Level 3 documentation at https://docs.coinapi.io/market-data/rest-api/order-book-l3/coinapi-market-data-rest-api.

background

Stay up-to-date with the latest CoinApi News.

By subscribing to our newsletter, you accept our website terms and privacy policy.

Recent Articles

Crypto API made simple: Try now or speak to our sales team