Skip to main content
Restricted access. Public API v2 is currently available only to allowlisted organizations. Requests from workspaces that have not been enabled are rejected. Contact your Reevo representative to have your organization added to the allowlist.

Pagination

_query endpoints and relationship reads return results one page at a time using cursors. Every _query endpoint (contact, account, opportunity, note, task, meeting, and custom objects) and every relationship read is keyset based, not offset based, so paging stays consistent as records change.

Page size

Set the page size with limit in the request body.
{
  "limit": 100
}
limit defaults to 50 and accepts a value from 1 through 100. A value outside that range is rejected with 400 limit_out_of_range, and the error details carry the offending limit and the allowed_range ([1, 100]).

The pagination block

List and _query responses return a data array plus a pagination block:
{
  "data": [],
  "pagination": {
    "current_cursor": null,
    "next_cursor": "b2Zmc2V0OjUw...",
    "prev_cursor": null,
    "total_count": 50
  }
}
FieldMeaning
current_cursorThe cursor for the page you just received. null on the first page.
next_cursorCursor for the next page. null when there are no more results.
prev_cursorCursor for the previous page. Always null: _query endpoints are keyset based and do not support backward paging.
total_countThe total number of records matching your filters. It is 0 when nothing matches.
Relationship reads use a different shape. They return count, items, and next_cursor (no current_cursor, prev_cursor, or total_count), and the count field is named count, not total_count.

Paging through results

When a response includes a next_cursor, send it back as cursor in your next request. Keep the same filters, sort, and limit across the whole run.
{
  "cursor": "b2Zmc2V0OjUw...",
  "limit": 100
}
Stop when next_cursor is null. Treat the cursor as an opaque string: do not parse, decode, or modify it.

Cursor lifetime

Cursors do not expire. There is no TTL, and a cursor carries no issued-at timestamp, so you can persist one and resume paging later. On _query endpoints, a cursor is bound to the filters and sort it was issued with. As long as those are unchanged, the cursor stays valid, even days later. Change the filter or sort and the cursor no longer matches: the request is rejected with 400 invalid_cursor, and you should restart from the first page with the new filter and sort. Relationship-read cursors bind to the parent record and relationship instead. Because pagination is keyset rather than a frozen snapshot, each page reads live data. Records created or updated between page reads are reflected according to the current sort. See Query Records for Sync for incremental sync patterns built on cursors.