QUANT_API
UTCSign inGet a key ↗
PRODUCT · 7 min read

A Polymarket Data API for Crypto Binary Options

A Polymarket data API with point-in-time, leak-free signals for crypto binary options — pm_microprice, pm_spread, plus crossing spot flow.

If you trade crypto binary options on prediction markets, your edge rarely comes from being right about the eventual outcome — it comes from being early. A Polymarket data API that exposes the order book and the spot microstructure feeding it lets you act before the book has finished repricing. This guide shows the polymarket.* signals QUANT_API serves, the crossing spot signals that move first, and why every value is computed leak-free.

Why prediction-market books reprice late

A Polymarket question like "Will BTC be above X by Friday?" is, in effect, a binary option on spot. But the prediction-market book is thinner and slower than a major perp venue. When real money hits BTC on Binance or Bybit, the spot tape — order flow, liquidations, funding — updates in milliseconds. The Polymarket quote often lags, because the marginal trader there is repricing a probability by hand, not running a market-making stack. That gap between spot microstructure and the polymarket order book is the structural inefficiency in crypto binary options.

The polymarket.* signals

To exploit the gap you need two things at once: a clean read of where the prediction market currently sits, and a leading read of the spot flow that should drag it. QUANT_API gives you both in one feature matrix, addressed the same way, so you are not scraping HTML or stitching websockets together for prediction market data. These four signals describe the Polymarket book itself:

  • polymarket.pm_microprice — the size-weighted fair value of the binary, a cleaner anchor than the last trade or the midpoint.
  • polymarket.pm_spread — the bid/ask width, your read on how liquid (and how trustworthy) the current quote is.
  • polymarket.pm_imbalance_top5 — depth imbalance across the top five levels, showing which side of the book is stacked.
  • polymarket.pm_momentum — short-horizon drift in the prediction-market price, useful to confirm the book has started moving (or hasn't yet).

The spot signals that move first

  • flow.ofi — order-flow imbalance on spot/perp, often the earliest sign of directional pressure.
  • liquidations.liq_imbalance — long-vs-short liquidation skew, which can force fast, one-directional moves the binary hasn't priced.
  • positioning.taker_ratio and funding.funding_avg — context on who is paying to hold the move and how crowded it is.

In practice the play is a comparison. Line up a spot lead — say a sharp positive flow.ofi@1m reinforced by a long-side liquidations.liq_imbalance@5m — against where polymarket.pm_microprice and polymarket.pm_momentum actually sit. When spot has clearly moved but the prediction-market book has not, you have a measurable, repeatable signal that the binary is mispriced relative to the underlying. polymarket.pm_spread and polymarket.pm_imbalance_top5 tell you whether there is enough depth to act on it without paying away the edge in slippage.

Every value is computed strictly from data with a timestamp at or before your as_of — no look-ahead, live or historical. So when you replay a settled question, the features reflect exactly what was knowable at decision time, not after the event resolved.

Pull all of these in a single request. Each signal is a category.signal@window[:transform] address, so you can ask for flow.ofi@1m, liquidations.liq_imbalance@5m, or a zscore of polymarket.pm_momentum@15m and get them back in one aligned row — browse the full set in the catalog. This matters more for event trading data than almost anywhere else: binary options resolve on a known outcome, and it is dangerously easy to build a backtest that quietly peeks at post-resolution information. QUANT_API's point-in-time guarantee removes that failure mode at the source, because the POST /v1/features/historical matrix is the same engine as GET /v1/features/live — a backtested decision and a live one see identical inputs.

Pull the live feature row

bash
curl -s -X POST https://api.quant-api.dev/v1/features/historical \
  -H "Authorization: Bearer fk_live_<secret>" \
  -H "Content-Type: application/json" \
  -d '{
    "asset": "BTC",
    "timestamps": ["2026-06-09T14:00:00Z", "2026-06-09T14:05:00Z"],
    "features": [
      "polymarket.pm_microprice@1m",
      "polymarket.pm_spread@1m",
      "polymarket.pm_imbalance_top5@5m",
      "polymarket.pm_momentum@15m:zscore",
      "flow.ofi@1m",
      "liquidations.liq_imbalance@5m",
      "positioning.taker_ratio@5m"
    ]
  }'

Swap historical for live to resolve the same address set as of now, or use GET /v1/features/series for a continuous window when you are charting the lag between spot and the binary. The catalog covers 161 signals across 14 windows and 9 transforms on BTC, ETH, SOL, XRP and BNB. One note on coverage: Kalshi is captured but not yet ingested, so it is coming soon rather than queryable today — the signals above are Polymarket-native and live now. For the methodology behind the addressing scheme and the point-in-time engine, see the docs and other guides.

Start free — 14-day Signal trial, no card
KEEP READING
Trading the post-liquidation-cascade reversalOrder Flow Imbalance (OFI): Why Aggressive Flow Leads PriceLeak-Free Backtesting: How to Kill Look-Ahead Bias