- /
api / snapshotEndpoint - up to 1 hourLookback
- UP +
DOWNReturns crypto_priceStamped
Sometimes you do not want a window, you want one moment. What was this market pricing the instant the print landed, the goal went in, the candle closed? The point-in-time lookup answers exactly that: hand it a timestamp and it returns the order book as it stood at that moment, both sides, with the spot reference stamped alongside.
The snapshots endpoint is for ranges; /api/snapshot is for instants. You give it a timestamp and a market, and it returns the single frame that describes the book as of that moment, not an average, not a window, one as-of view you can anchor a story to.
How the as-of lookup works
Markets do not emit a frame at every conceivable millisecond, so an exact-match lookup would often find nothing. Instead the endpoint searches backward: it returns the most recent snapshot at or before your timestamp, looking back up to one hour. That gives you the book as it last stood before your moment, the correct as-of semantics for reconstruction, because it never reaches forward to a frame that had not happened yet.
The most recent prior frame
The search only ever looks backward from your timestamp, up to an hour. That is deliberate: attaching the most recent prior record, never a later one, is what keeps a reconstruction honest. If nothing exists within the hour before your moment, the lookup returns empty rather than guessing.
What comes back
Both sides, derived
You get the UP and the DOWN token together, each with best bid, best ask, mid and spread already computed for that moment.
- UP + DOWN paired
- Touch and mid
- Spread pre-derived
Full book on request
Ask for the book and each side carries its complete bid and ask ladder as it stood, not just the touch.
- Whole ladder
- Resting size per level
- Optional payload
Spot reference stamped
The frame carries the crypto_price, the underlying spot at capture, so the market price and the spot it implied sit on one row.
- crypto_price field
- staleness in ms
- Market vs spot, aligned
That spot reference is what makes the lookup powerful for crypto. Every frame is stamped with the underlying price, BTC from Binance, for instance, and a staleness figure in milliseconds. So at the moment you are reconstructing, you see both what the prediction market was pricing and the spot it was pricing against, with no separate join required.
When to reach for it
- Event reconstruction, pin the timestamp of a print or a goal and read what the book looked like the instant before it.
- “What did the market price when X happened”, anchor a narrative or a post-mortem to one verifiable frame instead of a fuzzy window.
- Spot-vs-market checks, use the stamped crypto_price to ask whether the market had already moved with spot, or was lagging it, at that moment.
- Single-row references, cite one exact as-of state in a report, where pulling a whole window would be overkill.
Range query or point lookup?
They are different tools for different shapes of question. A range query answers “how did the book evolve across this stretch” and returns many frames. The point lookup answers “what was the book at this instant” and returns one. If you find yourself pulling a wide window only to keep the last frame before a moment, the point lookup is the cheaper, sharper instrument.
- timestampThe moment you want the book as-of
- ≤ 1 hour backHow far the search looks before your moment
- UP +
DOWNBoth tokens returned together crypto_priceSpot reference stamped on the frame
One honest caveat: this is a capture of the order book, not a settlement oracle. The frame tells you what the book was pricing at that moment, resting bids and asks, the mid they imply, and the spot it was pricing against. It does not tell you the final settled outcome; that is decided later, when the winning side goes to 1 and the loser to 0.
A range tells you the story; a point-in-time lookup gives you the still frame. Hand it the moment something happened, and it shows you exactly what the market believed an instant before.
Reconstruct a moment
The historical guide covers the point-in-time lookup and its as-of semantics; quant research shows how to fold it into event studies.
Frequently asked questions
What does the point-in-time snapshot lookup return?
It returns the single frame that describes the book as of your timestamp, both the UP and DOWN tokens, each with best bid, best ask, mid and spread already derived, the spot crypto_price stamped alongside, and the full bid/ask ladder if you request the book. One moment, both sides, one row.
What happens if there is no snapshot exactly at my timestamp?
The lookup searches backward and returns the most recent snapshot at or before your timestamp, looking back up to one hour. That gives you the book as it last stood before your moment. If nothing exists within that hour, it returns empty rather than reaching forward to a later frame.
Why does the snapshot include a crypto_price?
Each frame is stamped with the underlying spot at capture, BTC from Binance, for example, plus a staleness figure in milliseconds. That lets you read the prediction-market price and the spot it was pricing against on a single row, with no separate join, which is what makes the lookup useful for spot-versus-market reconstruction.
Does this tell me how the market settled?
No. The lookup is a capture of the order book at a moment, not the settlement oracle. It shows what the book was pricing, the resting bids and asks and the mid they imply, not the final outcome. Settlement is decided later, when the winning side resolves to 1 and the losing side to 0.