Polymarket Historical Data Resolutions - PolyOrderbooks

The resolution parameter controls bucket width for /prices, /metrics, and /books. Native capture runs at 1 second for open markets, and every plan can request 1s — including the free Starter tier. Plans differ on history window, not resolution — see Pricing.

Supported values

Resolution	Bucket size	Typical use
`1s`	1 second	High-frequency analysis; available on every plan
`60s`	1 minute	Intraday backtests over longer windows
`1m`	1 minute	Same bucket size as `60s`
`5m`	5 minutes	Order book snapshots, execution modeling
`10m`	10 minutes	Medium-frequency liquidity studies
`15m`	15 minutes	Session-level trend analysis
`1h`	1 hour	Multi-day dashboards
`6h`	6 hours	Weekly overviews
`1d`	1 day	Long-horizon research

Plan restrictions

Plan	Finest `resolution`	Max history
Starter	`1s`	3 days
Pro	`1s`	30 days
Pro 60d / Pro 90d / Pro 120d	`1s`	60 / 90 / 120 days
Enterprise	`1s`	Custom

Resolution is the same on every plan. Only the history window differs: queries with start_ts older than your lookback return HTTP 403 with the earliest allowed timestamp in the message. Check live limits on GET /v1/usage:

{
  "limits": {
    "granularity_allowed": "1s",
    "max_history_days": 3
  }
}

Selection guide

Scenario	Recommended resolution
Tick-level backtest	`1s` (Pro+)
Standard intraday bars	`60s` or `1m`
Slippage / depth analysis	`5m` on `/books`
Multi-week chart	`1h` or `1d`

Finer resolutions return more data points and consume more of your rate limit through pagination.

Timestamp format

Parameter	Format	Semantics
`start_ts`	ISO-8601 (`2026-07-26T00:00:00Z`) or Unix seconds	Inclusive
`end_ts`	ISO-8601 or Unix seconds	Exclusive

The query window is half-open: [start_ts, end_ts). Related reading: Historical Polymarket order book data for backtesting explains why capture cadence matters when reconstructing fills.