> ## Documentation Index
> Fetch the complete documentation index at: https://help.reevo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Pagination

> Page through Public API v2 results with cursors, including page size, the pagination block, and cursor lifetime.

<Warning>
  **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.
</Warning>

# 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.

```json theme={null}
{
  "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:

```json theme={null}
{
  "data": [],
  "pagination": {
    "current_cursor": null,
    "next_cursor": "b2Zmc2V0OjUw...",
    "prev_cursor": null,
    "total_count": 50
  }
}
```

| Field            | Meaning                                                                                                              |
| :--------------- | :------------------------------------------------------------------------------------------------------------------- |
| `current_cursor` | The cursor for the page you just received. `null` on the first page.                                                 |
| `next_cursor`    | Cursor for the next page. `null` when there are no more results.                                                     |
| `prev_cursor`    | Cursor for the previous page. Always `null`: `_query` endpoints are keyset based and do not support backward paging. |
| `total_count`    | The 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.

```json theme={null}
{
  "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](/Public-API-v2/Guides/Query-Records-for-Sync) for incremental sync patterns built on cursors.