How it works
The first request returns a page of results plus a next cursor. The client passes the cursor back to get the following page, until no cursor is returned. Because the cursor encodes a position, often a sort key and id, rather than a page number, inserts and deletes between requests do not cause skipped or duplicated records. Cursors can expire, so long-running jobs should handle that case.
Example
A sync job requests orders sorted by updated time. Each response includes next_cursor; the job stores the last cursor so it can resume exactly where it stopped after a deploy.
In integrations
Unify Int list endpoints are designed to return a next cursor on every page, whatever pagination the underlying platform uses. Combined with modified-since filters, cursors are the basis for reliable incremental sync. Persist cursors with your sync state, and treat an expired cursor as a signal to restart from a known timestamp rather than from the beginning.