Skip to main content
Large result sets paginate with opaque cursors. Pass cursors verbatim — do not decode or construct them manually.

​
Discovery lists

GET /v1/series, /v1/events, and /v1/markets return paginated catalogs:
Rules
  • Pass cursor=metadata.next_cursor on the next request.
  • Retain the same filters (search, tags, date bounds, sort, order).
  • When next_cursor is null, you have reached the final page.

​
Enumerating the full catalog

The default ordering is updated_at descending, and market rows are re-touched constantly as prices and liquidity move — roughly 1,200 markets per minute. With a descending sort, anything newly touched jumps to the front of the ordering, which shifts every page you have not read yet. A multi-page walk will then miss rows. Sort ascending when you need a complete pass. New and updated rows then land at the end, behind your cursor, so pages you have already read stay put:
sort=start_date is the better choice for a full pass because start_at belongs to the parent event and does not change once set, so a row never moves position mid-walk. updated_at ascending is stable against reshuffling but a row that gets updated moves behind your cursor and can appear a second time.
One caveat remains for any ordering: a market inserted mid-walk whose sort value falls before your cursor will not be seen on that pass. If you are mirroring the catalog, re-run periodically rather than assuming a single walk is exhaustive.

​
Historical time series

History endpoints paginate time buckets within [start_ts, end_ts):
When following cursors on history endpoints, reuse the same start_ts, end_ts, and resolution from the initial request.

​
Page size limits

Do not construct or decode cursors manually. Treat them as opaque tokens returned by the API.