Pagination and rate limits

Cursor pages

Every Organization API list answers { "data": [...], "has_more": true, "next_cursor": "…" }: send ?cursor=<next_cursor> back while has_more is true. The cursor is opaque: don’t build or change it. GET /v1/vault-items (Customer API) answers { "items": [...], "next_cursor": "…", "has_more": true }; /v1/audit-events keeps next_after.

/v1/logs pages newest first and filters by type, from/to, actor, level, status and q; short lists (alerts, access requests, external shares, handovers, weekly reports) also take since, until and q.

The Link header

Through passkey-x.com/api, every list with another page also answers Link: <…&cursor=…>; rel="next", so generic HTTP clients can follow pages without reading the body. offset= paging on the Organization API is deprecated: answers that use it carry Deprecation and Sunset.

URL='https://passkey-x.com/api/org/v1/members?limit=200'
while [ -n "$URL" ]; do
  curl -s -D headers.txt "$URL" -H "Authorization: Bearer $PASSKEY_X_API_KEY" | jq -c '.data[]'
  NEXT=$(grep -i '^link:' headers.txt | sed -n 's/.*<\([^>]*\)>; rel="next".*/\1/p')
  URL=${NEXT:+https://passkey-x.com$NEXT}
done

// Every page, following next_cursor (or Link rel="next") for you
for await (const event of org.org.auditEvents.iterate({ limit: 500 })) {
  console.log(event.sequence, event.action);
}
console.log(org.rateLimit); // { limit, remaining, reset, policy } from the last answer

Change feed

GET /v1/sync/changes returns a string cursor and has_more; store the cursor and send it back on the next call to get only what changed.

Rate limits

On 429, wait Retry-After seconds and back off with jitter. Watch RateLimit-Remaining and slow down before you reach zero; RateLimit-Reset says when the window starts again. A 304 Not Modified still counts.

Rate-limit headers