Pagination
Most Orbit list endpoints use cursor-based pagination for consistent, efficient navigation through large result sets — cursors keep your iteration stable even as new rows arrive. A subset of dashboard-oriented endpoint families use offset-based pagination instead. This guide covers cursor-based pagination first, then the offset-based endpoints and how to tell which style an endpoint uses.Overview
Every cursor-paginated response includes apagination object in the meta field:
Quick Start
First Page
Request without a cursor to get the first page:Next Page
Pass thecursor from the previous response to get the next page:
Continue Until Done
Keep paginating untilhas_more is false.
Parameters
Cursor-paginated endpoints accept these pagination parameters:Examples
Node.js — Iterate All Messages
Python / Go / Other languages
First-party SDKs for Python, Go, Java, Ruby, PHP, and .NET are built and in beta but not yet published to their package registries. Until then, hit the REST endpoint directly (requests, httpx, net/http, OkHttp, etc.) — the cursor pattern above maps 1:1 onto any HTTP client.
Best Practices
-
Use a reasonable page size. Most cursor-paginated list endpoints accept a
limitof up to 200; a few endpoint families cap lower (for example, 100). Offset-based endpoints set their own per-endpoint caps. Check the endpoint’s API reference entry for its exact maximum. For most use cases,20–50is sufficient. - Do not store cursors long-term. Cursors are opaque and may expire. They are meant for sequential iteration, not bookmarking.
-
Do not modify cursors. Cursors are server-generated tokens. Altering them will return a
400 Bad Request. -
Handle empty pages. If a page returns an empty
dataarray withhas_more: false, iteration is complete. - Combine with filters. Apply query filters alongside pagination to narrow results before iterating:
Cursor vs. offset pagination
Orbit uses two pagination styles depending on the endpoint. Most list endpoints are cursor-based; a number of dashboard-oriented endpoint families use offset-based pagination instead.
Cursor-based pagination is the default for high-volume, append-heavy collections (messages, notifications, audit logs, call lists, and most voice and messaging resources). Offset-based pagination is used where stable deep iteration matters less than jumping to a specific page.
Offset-based endpoints
Offset-based endpoints acceptlimit and offset query parameters and return the page inside the data envelope rather than in meta.pagination:
offset to skip rows and limit to size the page; total is the full count of matching rows. Offset depth is bounded on these endpoints (for example, the inbox ticket list caps offset at 10,000). To reach rows past the cap, narrow the result set with filters (status, date range) instead of paging deeper.
Endpoint families that use offset-based pagination today:
- Inbox tickets —
GET /inbox/tickets, plus the ticket companies roll-up, comments, and history. - Contact data (CDP) — account profiles, account scoring, and contact relationships.
- Compliance records.
- Reports and analytics goals.
- Surveys and referrals.
- Admin — organization, routing, and agent administration.
- Email suppressions.
meta.pagination.cursor field means cursor-based; a data.offset field means offset-based.