Skip to main content

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 optional nextCursor:

Basic usage

Pass cursorId and cursorTimestamp from the previous response’s nextCursor to fetch the next page:
Use the flat cursorId and cursorTimestamp parameters. The bracket notation form (cursor[id], cursor[timestamp]) is also supported but deprecated.

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

Use the generator pattern to process items as they arrive instead of loading everything into memory.
Always include rate limit handling in pagination code. Bulk fetches can hit the 300 requests/minute limit quickly.
Treat cursor values as opaque. Don’t modify or construct them manually — always use values returned from the API.

Query parameters

Encoding rules for complex parameters

Rate limits

Understanding API rate limits

List threads

Threads endpoint reference

List messages

Messages endpoint reference