Traverse cursor-based collections

List endpoints return a direct collection envelope:

{
  "data": [],
  "next_cursor": null
}

Pass limit between 1 and 100. When next_cursor is not null, pass it unchanged as the next request's cursor.

curl --fail-with-body \
  --get \
  --url 'https://api.accesspreflight.com/v1/scans' \
  --header "Authorization: Bearer ${ACCESSPREFLIGHT_API_KEY}" \
  --data-urlencode "project_id=${ACCESSPREFLIGHT_PROJECT_ID}" \
  --data-urlencode 'limit=100' \
  --data-urlencode "cursor=${NEXT_CURSOR}"

Cursor rules

• Treat a cursor as opaque; do not decode or modify it.
• Keep filters and tenant/project context identical between pages.
• Do not persist cursors as permanent bookmarks.
• Stop when next_cursor is null.
• Deduplicate by resource ID if your application lists concurrently changing data.

Changing environment, status, severity, automation, or another filter while reusing a cursor can produce a validation error or misleading client behavior. Start a new traversal instead.

Sync jobs

For periodic ingestion, store stable resource IDs and timestamps from records, not just the last cursor. Cursors describe one traversal position; they are not a cross-run change-data-capture contract.

Webhook event IDs plus periodic cursor traversal provide a practical combination of low latency and reconciliation.