Overview
The Inbox API uses cursor-based pagination for list endpoints that can return large datasets. This approach provides consistent results even when data changes between requests.Only
GET /threads and GET /threads/{threadId}/messages are paginated. Other list endpoints (GET /account-links, GET /members, GET /tags, GET /statuses) return all results as a flat array with no pagination.Response structure
Paginated endpoints return items and an optionalnextCursor:
Basic usage
PasscursorId and cursorTimestamp from the previous response’s nextCursor to fetch the next page:
Page size
Request more items per page to reduce API calls:
Streaming pattern
For real-time processing without loading everything into memory:Pagination with filters
Filters apply before pagination. The cursor tracks position within filtered results:Error handling
Handle rate limits and transient errors during pagination:Best practices
Stream for large datasets
Stream for large datasets
Use the generator pattern to process items as they arrive instead of loading everything into memory.
Handle rate limits in pagination loops
Handle rate limits in pagination loops
Always include rate limit handling in pagination code. Bulk fetches can hit the 300 requests/minute limit quickly.
Don't modify cursors
Don't modify cursors
Treat cursor values as opaque. Don’t modify or construct them manually — always use values returned from the API.
Related
Query parameters
Encoding rules for complex parameters
Rate limits
Understanding API rate limits
List threads
Threads endpoint reference
List messages
Messages endpoint reference