Pagination parameters
All collection endpoints support the following query parameters:Parameter | Type | Default | Description |
---|---|---|---|
limit | integer | 25 | Number of items to return (1-100) |
startingAfter | string | - | Cursor for forward pagination |
endingBefore | string | - | Cursor for backward pagination |
orderBy | string | createdAt | Field to sort by |
sort | string | desc | Sort direction (asc or desc ) |
How it works
- Initial Request: Make a request without pagination parameters to get the first page
- Get Next Page: Use the
id
of the last item asstartingAfter
- Get Previous Page: Use the
id
of the first item asendingBefore
- Check for More: If the returned items equal the limit, more pages may exist
Basic pagination example
Sorting results
You can sort results by any field that’s included in the response:Getting total count
To get the total number of items without fetching all data, use the count endpoint:Combining with filters
Pagination works seamlessly with filtering and search:Best practices
1. Choose appropriate page sizes
- Use smaller limits (10-25) for real-time UI updates
- Use larger limits (50-100) for batch processing
- Maximum limit is 100 items per request
2. Handle edge cases
3. Implement progress tracking
4. Optimize for performance
- Use field selection to reduce payload size
- Process pages in parallel when order doesn’t matter
- Cache results when appropriate
Common patterns
Bidirectional navigation
Infinite scroll implementation
Troubleshooting
No results returned
If you’re not getting expected results:- Check if filters are too restrictive
- Verify the cursor ID exists and belongs to the same resource type
- Ensure you’re not mixing
startingAfter
andendingBefore
Performance issues
For better performance:- Use larger page sizes (up to 100)
- Limit the fields returned with
select[]
- Use count endpoint separately instead of fetching all data
- Consider caching results for static data