polyReplay Alternative for Polymarket Historical Data

Checked on August 18, 2026, from outside their network:

polyreplay.dev/            402  "This deployment is temporarily paused"
www.polyreplay.dev/pricing 402  "This deployment is temporarily paused"
api.polyreplay.dev/        no response

DNS still resolves, so this looks like a paused deployment rather than a withdrawn domain. A paused deployment can be restored, so treat the above as observed status on a date rather than a permanent shutdown announcement. What it means practically: the REST API and the Parquet bulk downloads are not currently reachable, so existing users cannot pull their archive right now.

Because their site is down, the figures below describe what polyReplay documented publicly before it went offline. We can no longer link a live source for them, which is worth knowing when weighing this comparison.

polyReplay figures reflect its public documentation before the site went offline; PolyOrderbooks figures from our own documentation.Scroll →

polyReplay documented 5m, 15m, and 4h Up-or-Down markets with sub-150ms tick books, trades, and Binance spot joins — strong for narrow tick research on those rounds. Two of those properties were genuinely better than what an ongoing 1-second archive gives you, and it is worth being precise about that:

• Sub-150ms capture. Finer than 1-second sampling. If your research depends on the order of events inside a second, that resolution is not something PolyOrderbooks reproduces.
• Pre-joined Binance spot. The reference feed arrived aligned to the book ticks, which removes a fiddly timestamp-alignment step from your pipeline.
• File-based delivery. Per-market Parquet and whole-day bundles suit batch workflows that want the whole dataset local before analysis.

If your work sits entirely inside the archive window and needs sub-second sequencing, those files remain the better source for it in principle — the practical problem is that they are not currently downloadable.

Capture stopped July 17, 2026, when Polymarket became unavailable in the jurisdiction their collector ran from. With the site now unreachable as well, there are four consequences worth planning around:

• No access to your own history. Neither the REST API nor bulk downloads respond, so pipelines that read polyReplay at runtime are broken now, not degraded.
• No recent regimes. Nothing after mid-July 2026 was ever captured, so strategies cannot be validated against current volatility, spreads, or liquidity.
• No forward testing. A stopped collector cannot support paper trading or ongoing monitoring — only retrospective study of a fixed window.
• Local copies are now the only copies. If you exported Parquet files earlier, treat them as irreplaceable and back them up. If you did not, assume that data is gone rather than waiting for the service to return.

Map workflow to workflow rather than field to field — the delivery models differ enough that a literal translation will mislead you.

No polyReplay SDK is published on PyPI, so pipelines generally read its REST API or downloaded Parquet directly. The PolyOrderbooks equivalent uses the official polyorderbooks client:

# polyReplay (closed archive — capture ended July 17, 2026)
# Typically: download per-market Parquet, or read its REST v1 endpoints,
# then join the pre-aligned Binance spot column locally.

# PolyOrderbooks — query the ongoing archive
import os
from polyorderbooks import PolyOrderbooksClient

client = PolyOrderbooksClient(api_key=os.environ["POLYORDERBOOKS_API_KEY"])

# Discover instead of assuming a slug template
markets = client.list_markets(search="btc", limit=5)
slug = markets["data"][0]["slug"]

books = client.get_market_books(
    slug,
    start_ts="2026-08-01T00:00:00Z",
    end_ts="2026-08-01T06:00:00Z",
    resolution="1s",   # 60s on Starter; 1s on Pro and Scale
    limit=100,
)

for outcome, points in books["data"].items():
    for point in points[:2]:
        bids = point.get("bids") or []
        asks = point.get("asks") or []
        print(point["t"], outcome, "bid", bids[0][0] if bids else None,
              "ask", asks[0][0] if asks else None)

client.close()

Paginate long windows with client.iter_market_books(...) rather than raising limit. Full endpoint reference is in the historical data docs.

Four places a ported pipeline usually breaks:

• Depth shape. polyReplay served fixed-depth snapshots; PolyOrderbooks returns the full ladder as b and a arrays. Code that assumes a fixed number of levels per side needs to handle variable depth.
• Time semantics. Tick-driven rows become fixed-interval samples. Logic that treated each row as "the book changed" must now treat it as "the book at this second".
• Outcome keying. Books come back keyed by outcome, so YES/NO handling is a dictionary walk rather than separate files per outcome.
• No reference feed. Binance spot is not included. Source it separately and align on timestamps yourself.

Download the free BTC 5-minute L2 sample and run it through your existing parser before rewriting anything — it has the same ladder shape the API returns.

No. Delivery differs (REST queries rather than Parquet files), capture cadence differs (1-second rather than sub-150ms), and the Binance spot join is not provided. It replaces polyReplay for ongoing Polymarket crypto order book history — discovery, prices, liquidity metrics, and full L2 depth that keeps updating.

It does not reproduce sub-second tick sequencing. If that is your requirement and you already hold polyReplay exports, keep them and use PolyOrderbooks for everything after July 2026 — running both is a reasonable end state. If you never exported, sub-150ms Polymarket history for that window is not something we or, as far as we know, anyone else can sell you.

PolyOrderbooks targets multiple crypto market types with 1-second capture and REST query access — a better fit when you need ongoing data beyond one Up/Down template. Start with the full provider matrix if you want to weigh other archives against it before committing.