- Full bookDepth
- Event +
captureTimestamps - PreservedClosed markets
- ~20 Hz (BTC)Capture
Most prediction-market backtests fail quietly, not because the strategy was bad, but because the data could not support an honest test. Before you trust a bot’s backtest, check that the data underneath it has the four things that separate a credible result from a fantasy.
The strategy gets all the attention, but the dataset decides whether the result means anything. These are the properties that matter, and where thin data quietly breaks a backtest.
What a credible backtest needs
Full order-book depth
You cannot model slippage from top-of-book alone. The full bid/ask ladder lets you fill at the price you would really pay.
- Whole ladder, not the touch
- Honest slippage
- Size against real depth
Trustworthy timestamps
Event and capture timestamps let you reconstruct what was knowable at each instant and avoid lookahead bias.
- No future leakage
- Latency-aware
- Millisecond precision
Resolved markets kept
If closed markets vanish, your sample is only survivors, a biased view. Preserved history fixes that.
- No survivorship bias
- Hundreds of resolved markets
- Batch-testable
What to be wary of
- Top-of-book only, fine for a chart, useless for modelling fills on size.
- Sparse sampling, a few snapshots a minute hides the fast moves that decide short-horizon strategies.
- Live-only data, if you can only see markets that are currently open, your backtest is survivorship-biased.
- Mid-price fills, a backtest that fills at the mid overstates returns by half the spread, every trade.
A backtest is a claim about the past. The order book, not the mid-price, decides whether that claim is one you could actually have executed.
The fields that make a fill honest
Each snapshot carries the full ladder plus two clocks, and that combination is what lets a backtest reconstruct a realistic fill rather than a hopeful one. You walk the bids and asks to fill your size at the prices that were really there, and you use the timestamps to be sure you only acted on information that existed at the moment.
- bids[] /
asks[]Full ladder, fill across levels, not just the touch - event +
capture tsTwo clocks, reconstruct what was knowable, no lookahead sequence_numberMonotonic counter, detect gaps in the stream- spread /
depthPre-derived metrics for cost and liquidity checks
Ways to pull the history
REST snapshots
Query a market’s snapshots by side and time range, with paging up to 5,000 rows and an option to include the full book.
- Filter by side and time
- Paginate large pulls
- Include or skip the ladder
Bulk export
The rm-api CLI streams CSV, JSON, or JSONL and can sync to a local SQLite file for offline backtests.
- CSV / JSON / JSONL
- Local SQLite sync
- Batch-friendly
MCP for agents
The MCP server exposes the same read-only history to AI agents, every tool available on every tier.
- Read-only by design
- 12 tools, all tiers
- Analysis, not execution
What this data is, and isn’t
We capture full-depth order-book snapshots and resolved-market history for crypto, sports, economics, weather, social, and equities markets. We do not expose a per-trade tape, so volume-based indicators are out of scope, and we say so plainly. The platform is read-only: it powers analysis and monitoring, and never places trades for you. Knowing exactly what the dataset covers is part of trusting a backtest built on it.
Test on real history
Run a strategy in the visual builder, or pull the snapshots and backtest in your own stack.
Frequently asked questions
What data do I need to backtest a Polymarket bot properly?
Full order-book depth (to model fills and slippage honestly), trustworthy timestamps (to avoid lookahead bias), and preserved history for resolved markets (to avoid survivorship bias). High capture frequency matters too, so short-horizon moves are not hidden between sparse samples.
Does Resolved Markets provide per-trade volume data?
No, and we are upfront about it. The platform exposes full-depth order-book snapshots, not a per-trade tape, so volume-based indicators like VWAP or money-flow are out of scope. The order book supports spread, depth, imbalance, and price-action strategies.
Why does survivorship bias matter for bot backtests?
If your dataset only contains markets that are currently open, you are testing on survivors and ignoring everything that already resolved, a skewed sample. Because resolved markets are preserved here, you can backtest across the full population, which makes the result more honest.
How do event and capture timestamps prevent lookahead bias?
Each snapshot carries both the event timestamp (when Polymarket emitted the change) and the capture timestamp (when we recorded it). A backtest replays the book in that order and only acts on information that existed at the moment, so it never leaks a future price into a past decision. The sequence_number on each snapshot also lets you detect any gaps in the stream before you trust a run.