Skip to main content

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 a pagination object in the meta field:

Quick Start

First Page

Request without a cursor to get the first page:

Next Page

Pass the cursor from the previous response to get the next page:

Continue Until Done

Keep paginating until has_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

  1. Use a reasonable page size. Most cursor-paginated list endpoints accept a limit of 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–50 is sufficient.
  2. Do not store cursors long-term. Cursors are opaque and may expire. They are meant for sequential iteration, not bookmarking.
  3. Do not modify cursors. Cursors are server-generated tokens. Altering them will return a 400 Bad Request.
  4. Handle empty pages. If a page returns an empty data array with has_more: false, iteration is complete.
  5. 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 accept limit and offset query parameters and return the page inside the data envelope rather than in meta.pagination:
Pass 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 ticketsGET /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.
All other list endpoints use cursor-based pagination as described above. When in doubt, check the response: a meta.pagination.cursor field means cursor-based; a data.offset field means offset-based.