Skip to main content
All list endpoints use cursor-based pagination. You don’t pass page numbers — instead you pass the id of the last row you saw, and we return the next slice.

​
Request parameters

​
Response shape

  • data — the page of items, ordered most-recent-first.
  • has_more — true if more pages exist after this one.
  • next_cursor — pass this as starting_after on the next request. null when there is no next page.

​
Walking the full list

Keep going until has_more is false.

​
Why cursors, not offsets?

Cursors don’t drift when rows are inserted or deleted between requests. Offset pagination (page=2) can miss items or return duplicates if data changes mid-walk; cursors stay anchored to a specific row.

​
Stable ordering

Rows are ordered by (created_at desc, id desc) for most resources, and (visit_date desc, id desc) for site visits. The compound order makes cursoring deterministic even when many items share the same timestamp.