Skip to main content

Pagination

Ticksupply uses cursor-based pagination for endpoints that return lists of items. This approach provides stable, consistent results even when data changes between requests.

How pagination works

Paginated endpoints accept two query parameters: Default limits vary by endpoint: The response includes pagination metadata:

Basic pagination

First page

Request the first page without a page_token:
Response:

Subsequent pages

Use the next_page_token from the previous response:

Last page

When there are no more items, next_page_token is null:

Complete pagination example

Generator pattern

For memory efficiency with large datasets, use a generator pattern:

Cursor stability

Cursor-based pagination provides stable results:
Unlike offset-based pagination, cursor pagination doesn’t skip items when new data is added or duplicates items when data is deleted.
Results are ordered by creation time (newest first) and ID. This ordering remains stable across pages.
Treat page tokens as opaque strings. Don’t parse, modify, or construct them—only use tokens returned by the API.
Page tokens may expire after extended periods. If you receive an error with an old token, start from the first page.

Best practices

Use appropriate page sizes

  • Small datasets: Use default limits or smaller for quick responses
  • Bulk operations: Use maximum limit (100 for subscriptions/exports, 1,000 for catalog) to reduce API calls
  • UI pagination: Match your UI’s display capacity

Handle rate limits during pagination

When paginating large datasets, implement rate limit handling:

Don’t store page tokens long-term

Page tokens are meant for immediate pagination, not long-term storage:

Paginated endpoints

Next steps

Error Handling

Handle API errors gracefully in your application

Rate Limiting

Understand rate limits and how to handle them

Idempotency

Safely retry requests using idempotency keys

API Reference

Explore the complete API documentation
Last modified on April 17, 2026