[Polymarket] CLOB /orderbook-history endpoint no longer returns data (affects PolymarketDataLoader)

[JSai23]

Bug Report

Confirmation

• I've re-read the relevant sections of the documentation.
• I've searched existing issues and discussions to avoid duplicates.
• I've reviewed or skimmed the source code (or examples) to confirm the behavior is not by design.
• I've tested this issue using a recent development wheel (dev develop or a nightly) and can still reproduce it.

Expected Behavior

PolymarketDataLoader.fetch_orderbook_history() (in nautilus_trader/adapters/polymarket/loaders.py, around line 758) should return orderbook snapshots when querying the Polymarket CLOB /orderbook-history endpoint for an active market within a recent time window.

The function paginates through https://clob.polymarket.com/orderbook-history using asset_id, startTs, endTs, limit, and offset parameters, accumulating snapshot data until all pages are fetched.

Actual Behavior

The CLOB /orderbook-history endpoint stopped producing new orderbook snapshots around Feb 20, 2026 ~20:00 UTC. Any query with a time window after this cutoff returns {"count": 0, "data": []}. This means fetch_orderbook_history() will always return an empty list for any recent time range, silently producing no data.

Historical data from before the cutoff is still accessible. For example, querying a known active token for a window around Feb 12 returns results normally:

asset_id=113331598718835447619835372415650100713271301516293755503999990681415131593110
startTs=1770898200000  (Feb 12 ~18:30 UTC)
endTs=1770898500000    (Feb 12 ~18:35 UTC)
-> count: 226

The same token for any post-Feb 20 window:

startTs=1771977600000  (Feb 21 00:00 UTC)
endTs=1772063999000    (Feb 21 23:59 UTC)
-> count: 0

This has been confirmed across multiple high-volume markets (BTC $150k, US Strikes Iran, etc.) — it is a platform-wide issue, not market-specific.

Other CLOB endpoints are unaffected:

• /book?token_id=... returns live bids/asks normally
• WebSocket streams (price_changes, etc.) continue to work
• /midpoint, /last-trade-price, /spread, /prices-history all return current data

Steps to Reproduce the Problem

1. Pick any active Polymarket token ID (e.g., 37297213992198847758335843642137412014662841314020423585709724457305615671955 — BTC $150k Feb)
2. Query the endpoint with a recent time window:

   curl -sG 'https://clob.polymarket.com/orderbook-history' \
       --data-urlencode 'asset_id=37297213992198847758335843642137412014662841314020423585709724457305615671955' \
       --data-urlencode "startTs=$(($(date +%s) * 1000 - 3600000))" \
       --data-urlencode "endTs=$(($(date +%s) * 1000))" \
       --data-urlencode 'limit=500' \
       --data-urlencode 'offset=0'

3. Observe {"count":0,"data":[]}
4. Compare with a pre-cutoff window (before Feb 20 2026 20:00 UTC) on a token that was active at that time — data is returned normally

Code Snippets or Logs

The affected code path in nautilus_trader/adapters/polymarket/loaders.py (line ~758):

async def fetch_orderbook_history(
    self,
    token_id: str,
    start_time_ms: int,
    end_time_ms: int,
    limit: int = 500,
) -> list[dict[str, Any]]:

This function will silently return an empty list for any time range after the cutoff, with no error or warning — the endpoint responds with valid JSON, just empty data.

Additional Context

The /orderbook-history endpoint is undocumented in Polymarket's official API docs. It appears to have been part of infrastructure originally associated with Dome (domeapi.io), which was acquired and rebranded as Predexon. The ingestion pipeline behind this endpoint may have been deprecated or broken during that transition.

This is an upstream Polymarket platform issue, not a nautilus_trader bug per se, but it directly breaks the PolymarketDataLoader orderbook history functionality. Possible mitigations:

• Log a warning when the endpoint returns empty data for a time range where data would be expected
• Consider alternative data sources (e.g., Predexon API at api.predexon.com serves similar data with different param names)
• Document the limitation for users relying on orderbook history backfill

Specifications

• OS platform: Linux (Ubuntu 24.04)
• Python version: N/A (tested endpoint directly via curl)
• nautilus_trader version: develop branch (commit 5f8468cb)

[cjdsellers]

Hi @JSai23

Thank you for the report.

It does appear the order book history API has been decommissioned. This has now been removed with the backtest example replaced to use the working Polymarket Data API (data-api.polymarket.com/trades) for trade execution history.

The synthetic price history path has also been removed as it only returned midpoint prices and do doesn't match well with the Nautilus domain model.

I'll update the release notes accordingly.

[JSai23]

I'm actually curious how this endpoint was discovered. I highly doubt that the data is truly unavailable anymore. This endpoint was great overall due to granularity. The trades endpoint doesn't hang anywhere near as granular data. This endpoint provided multiple snapshots a second while trades endpoint is at 1m interval or above.

[coyevans13]

Confirming this is still the state in mid-2026 for anyone arriving from search: Polymarket's /orderbook-history did not come back, so historical L2/book reconstruction now means either a third-party back-capture (Telonex, PMData, PolymarketData) or running your own WS recorder going forward via the real-time-data-client. Predexon (mentioned above) does serve similar fields with renamed params and is worth a look.

One adjacent gap I hit and couldn't buy anywhere: the book time-aligned with Kalshi in the same window, and (for sports) with live game state on each row. I put a free sample of that up in case it helps anyone building a cross-venue or sports backtest on top of Nautilus: https://huggingface.co/datasets/Coyevans/polymarket-kalshi-scoresync-orderbook-sample (CC-BY-NC, parquet/CSV). Strictly research/backtest data — not a signal, these markets are efficient — but the score-synced cross-venue structure is the part you can't rebuild after the fact.