If interval snapshots answer the question, use checkpoint history. If the answer depends on events between checkpoints, use order-level data such as L4, order flow, or TP/SL history.
If you are choosing between native venue data and managed history, compare the two sources here.
Short answer: checkpoint history is enough when you care about state at intervals and do not need to explain what happened inside them. Order-level depth becomes necessary when queue movement, trigger behavior, user attribution, or intra-interval order flow can change the answer.
Three practical layers of depth
Every level from the best bid to the wallet, shown on one order book, is in level 1 vs level 2 vs level 3 market data.
Layer | Typical surface | How to decide |
|---|---|---|
Top-line market history | Trades, candles, funding, open interest, liquidations | Use it when you need regime context, timing, or broad filters, not state reconstruction. |
Checkpoint history | Replay state and | Use it when interval state is enough and you need reproducible reruns. |
Order-level depth |
| Use it when the answer changes because of what happened between checkpoints. |
Route-level guide
Question | Public route or surface to inspect first | Why |
|---|---|---|
Can replay alone explain the event window? | Start with replay lifecycle and state handling before you assume you need deeper depth. | |
Do I need checkpoint state at intervals? | Checkpoint history is the first test when interval snapshots may already preserve the answer. | |
Do I need to study order placement and cancellation pressure? | Order flow helps when the path between checkpoints matters more than the checkpoint itself. | |
Do triggers or TP/SL events matter? | Trigger history shows the sequence of trigger events when that sequence matters to the answer. | |
Do I need full order-level reconstruction? |
| Full L4 is for path-dependent questions where interval checkpoints are not enough. |
When checkpoint history is enough
You want replayable snapshots for backtests and incident reviews.
You are measuring changes at discrete intervals rather than queue behavior tick by tick.
You need something closer to state reconstruction than candles offer, but not user attribution or trigger history.
You care more about repeatable reruns than every intra-interval order mutation.
Replay and order-level data are available on every plan. Free covers the most recent 30 days; Build and above include the full retained archive. Compare current plan limits for history and capacity, and use the REST API docs for endpoint details.
Do not buy depth for these cases
Broad regime filters, volatility context, and top-line event timing.
Discrete replay snapshots that already explain the incident window.
Offline studies where a checkpoint or export already preserves the state you need.
Cases where you are only reaching for depth because it feels safer, not because the answer changes between intervals.
When order-level depth is actually necessary
You are studying queue position, microstructure behavior, or what happened between checkpoints.
You need to inspect order flow, TP/SL triggers, or user-attributed order behavior.
You need full L4 reconstruction rather than interval checkpoints alone.
You are investigating path-dependent events where the order sequence matters as much as the resulting state.
One-symbol depth test
Compare checkpoint and order-level data for the same symbol and event window. Use order-level data when the explanation depends on events between checkpoints.
Pick one event window where the answer may depend on intra-interval behavior.
Review it first through checkpoint history or replay.
Write down what remains unresolved.
If the unresolved question lives inside the interval, inspect the matching order-level route.
Use the parity guide to compare the work required to reproduce the same window natively and with managed history.
Choose a plan for history and capacity
The question determines the data depth. The current plan limits determine the history window, credits, throughput, replay speed, and export capacity.
Create a key and test one event window. Inspect order-level data if checkpoints leave the question unanswered.