Skip to main content
List endpoints return their results in pages. Each response carries one page of items and a cursor that points to the next page, so you can walk through a long list without skipping or repeating items while new ones are being created. Every paginated endpoint works the same way, and its page lists the limit and next query parameters.

​
Query parameters

​
integer
default:15
Maximum number of items in the page. An endpoint can set its own default or maximum; when it does, its page shows it.
​
string
Cursor of the page you want: the next value of the previous response. Omit it to get the first page.

​
Response

Every paginated response has the same two fields:
​
object[]
The items on this page, in the endpoint’s order. Each item has the fields documented on the endpoint’s page (abbreviated above).
​
string | null
Cursor for the next page. null when this is the last page.

​
Best practices

​
Use appropriate page sizes

Choose a limit that balances performance and usability. Smaller pages suit interactive screens, while larger pages (hundreds of items) work better for bulk processing.

​
Handle pagination gracefully

Request another page only while next has a value. On the last page it’s null, and responses don’t include a total count. Send next back exactly as you received it, with the same filters and sort order, and don’t build or parse it.

​
Consider rate limits

Be mindful of rate limits when paging through large datasets. Space out your requests or batch your work when you process many pages.