For the complete documentation index, see llms.txt. This page is also available as Markdown.

Pagination

Responses to broad requests can return more results than fit in a single page. This tutorial covers how to walk through large result sets using cursor-based pagination.

10 minutes Skill level: Beginner Prerequisites: Make your first request

Why pagination exists

A request like "all drivers" or "all fixtures" can return thousands of records. Returning everything in one response would be slow and difficult to work with. Instead, the API splits results into pages and gives you a cursor to fetch the next one.

The pagination object

Every paginated response includes a pagination object at the end of the response body:

{
  "data": [ ... ],
  "pagination": {
    "count": 25,
    "per_page": 25,
    "current_page": 1,
    "next_cursor": "WzEsMixbMTk3MTAxMDBdLFtbInNwb3J0cy5maXh0dXJlcy5pZCIsMV1dXQ",
    "has_more": true
  }
}

has_more tells you whether there are additional pages. next_cursor is the value you pass on your next request to retrieve them.

Walking through pages

  1. Make a standard request with no cursor.

  2. Use per_page to control how many results come back per page (range 1-50, default 25).

  3. Take the next_cursor value from the response and pass it as a cursor parameter on your next request.

  4. Repeat until has_more is false.

When there are no more pages, the response looks like this:

Code example

Populating a database

If you are populating your own database rather than displaying live results, add filters=populate to raise the pagination limit to a maximum of 1000 per page. Note that includes are disabled when this filter is used, to prevent overloading the API.

Common pitfalls

Treating the cursor as reusable. A next_cursor value is only valid for the next request in the sequence. Do not store it and reuse it after fetching other pages.

Forgetting that every page counts against your rate limit. Fetching pages 1 through 10 counts as 10 calls against the relevant entity's hourly limit, not one.

Mixing page-number pagination with cursor pagination. The older page= parameter is still supported for existing integrations, but mixing it with cursor= in the same request produces undefined behaviour. Pick one approach per integration.

FAQ

Is the old page-number pagination still supported? Yes, for existing integrations. New integrations should use cursor-based pagination since it is faster and puts less load on the API.

What is the maximum per_page value? 50 by default, or up to 1000 when using filters=populate (with includes disabled).

Last updated

Was this helpful?