Got a million users? That's a lot of license records.

Most of our routes don't require any pagination, for the ones that do (namely List Licenses) we use token-based pagination. If you've ever used an API to move across large data sets like Twitter or Gmail, you're probably already familiar with the concept.

In essence, when the results for an API call exceed the max-results (we cap ours at 1000 records), your response body includes a nextPageToken value. If you want to get the next 1000 results in the list, you call the API again, with all the same request details BUT you include the query parameter pageToken={nextPageToken}. This lets our service know where to pick back up the list.

If you want to iterate over the entire list, just keep looping until nextPageToken == null.

One notable quirk of high-volume APIs like our List Licenses endpoint, is returning an approximation of the total number of results instead of an exact count. Exact row counts are slow on large data sets, memory intensive, and likely to be out of date by the time it gets to you anyways 😅.

Instead we (and many other companies) opt for an approximation, since the exact number is pretty useless. More often than not, as developers, we use this number to gauge size, performance, and viability of our design. Then we use the page tokens to move through the list.

What’s Next

Check out our pagination in action