Polymarket trading bot: data feeds and historical L2 depth for automation

A Polymarket trading bot is modular — market discovery, a data feed, execution decisions, and risk controls. The trading bot architecture guide covers the pattern; the data feed is what PolyOrderbooks provides: historical L2 order books, prices, and liquidity metrics over REST.

Each market's slug resolves to full bid/ask ladders captured every 250ms, with aligned prices and metrics on the same timestamps, so a bot can see depth, spread, and mid at the same instant.

• REST — books, prices, and metrics share the same 250ms-to-1d resolution grid and per-key limits, documented in the rate limits guide.
• Python SDK — `pip install polyorderbooks` wraps discovery, order books, prices, and metrics.
• MCP server — market search plus order book and metrics history exposed as tools for Cursor or Claude agents: `search_markets`, `get_order_book_history`, `get_market_metrics`, and more.
• Resolved markets stay — past books remain queryable with their winning outcome, so replays and backtests keep working after settlement.

A bot on Polymarket is two loops: a decision loop that reads prices and books, and an execution loop that places orders. Both are thin here, because the venue is a small tick grid — the 0.99 and 0.995 bound prices, the ladder with sizes, the executable side rather than the mid — and the data feed must carry those precise fields without a guessing layer in between.

The feed that keeps a bot honest is the same one every study on the site uses: full L2 order books at 250ms over REST, with prices and metrics on the same timestamp grid. Alive bot reads the current book over HTTP and subscribes for faster updates; a historical replay uses the same rows to test the strategy over thousands of resolved contracts before a single live order.

The single most common bot failure here is quoting the mid. On books that are one-sided 16.9% of the time, there may be no executable mid at all, so a bot that computes prices from the average of bids and asks is breeding orders it cannot fill, or will fill at its own slippage.

The safe deployment is staged: replay the strategy over the resolved archive, then run paper rules against live books for a week, then switch to real orders with small sizes while the exit logic logs every fill reason. The archive makes each stage a replay problem rather than a trust problem.

A bot built on this feed inherits the same discipline as the research pages: quote the executable side, log the UTC second, reconcile fills against the stored book, and treat the free Starter window as the sandbox before any paid tier is justified.

The deployment ladder is the same discipline every study on this site follows: replay the rules over resolved books, paper trade against the live feed, then size real orders down while the exit log reconciles against the stored frames.

Instrument the book: log the executable side and the distance to the bound on every tick, because those two fields explain the majority of fill failures on this venue.

Watch the final minute: 76.2% of snapshots in 5-minute markets have an empty bid or ask side near settlement, so a bot not built to see a one-sided book will misprice exactly when it has the least time to recover.

Add a crossed-book guard: 3.24% of snapshots are crossed, and any order placed off a crossed book should be held rather than chased.

Keep the feed and the order log on the same UTC clock — the archive timestamps by second, and a bot whose decisions cannot be joined to the recorded book may as well not be logging at all.

• Order book data
• Rate limits
• Trading bot architecture
• MCP server