Skip to main content
All list endpoints in the Organization and Enterprise APIs use cursor-based pagination. This provides consistent, efficient pagination regardless of the size of the result set.

How it works

Every list endpoint accepts two query parameters:
ParameterTypeDescription
firstintegerMaximum number of items to return per page (default varies by endpoint)
afterstringOpaque cursor from a previous response. Omit for the first page

Response format

List responses include pagination metadata:
FieldDescription
itemsArray of results for the current page
has_next_pagetrue if there are more results
end_cursorPass this as the after parameter to get the next page. null when has_next_page is false
totalTotal number of matching items (may be omitted by some endpoints for performance)

Example: Paginating through sessions

First page

Next page

Use the end_cursor value from the previous response:

Collecting all results

Migrating from offset-based pagination

If you’re migrating from API v1 or v2, replace offset/limit with after/first:
Cursor-based pagination is more reliable than offset-based pagination because it isn’t affected by items being added or removed between pages.