Overview
The Inbox API uses cursor-based pagination for all list endpoints. This approach provides consistent results even when data changes between requests.Response Structure
Paginated endpoints return items and an optionalnextCursor:
| Field | Description |
|---|---|
items | Array of results (key varies: threads, messages, tags, etc.) |
nextCursor | Object containing id and timestamp. null when no more pages. |
Basic Usage
Cursor Encoding
Cursors are objects that must be encoded in query parameters using bracket notation. Cursor object:Page Size Limits
| Endpoint | Default Limit | Maximum Limit |
|---|---|---|
/threads | 50 | 100 |
/threads/{id}/messages | 50 | 100 |
/tags | 50 | 100 |
/statuses | 50 | 100 |
/members | 50 | 100 |
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 pagination errors gracefully:Best Practices
Use maximum page size for bulk operations
Use maximum page size for bulk operations
Reduce API calls by requesting the maximum 100 items per page when fetching all data.
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 limits quickly.
Don't modify cursors
Don't modify cursors
Treat cursor objects as opaque. Don’t modify or construct them manually.