Pagination

The verification log is cursor-paginated, newest first. Cursors are stable under concurrent writes: a verification recorded while you are paging does not shift rows onto a page you have already read.

The loop

Ask for a page, then follow pagination.nextCursor until pagination.hasMore is false.

curl -s "https://api.audrie.io/v1/verifications?limit=50" \
  -H "Authorization: Bearer $AUDRIE_API_KEY"

{
  "data": [ { "verificationId": "3c0d9a2e-77b1-4f0a-8a11-d1e2f3a4b5c6", "verdict": "verified" } ],
  "pagination": {
    "nextCursor": "MjAyNi0wOC0yMVQwNDoxMTowOVosM2MwZDlhMmUt…",
    "hasMore": true
  }
}

curl -s "https://api.audrie.io/v1/verifications?limit=50&after=$NEXT_CURSOR" \
  -H "Authorization: Bearer $AUDRIE_API_KEY"

Stop on hasMore, not on an empty data array. They are different signals, and only hasMore is the contract.

Parameters

nextCursor is opaque. Pass it back verbatim; do not parse it, construct one, or carry one across a change of filters.

Filters

verdict, originalDocHash, from and to narrow the log. They combine, and they apply to the whole result set rather than to one page — so keep them identical across every request in a paging loop.

curl -s "https://api.audrie.io/v1/verifications?verdict=revoked&from=2026-08-01T00:00:00Z" \
  -H "Authorization: Bearer $AUDRIE_API_KEY"

Bad input is refused, never ignored

An unparseable from or to, a limit outside 1–100, an unknown verdict, a malformed hash, or a cursor that does not decode all return 400 with the offending field named in error.details.

Nothing is silently clamped or dropped. On a log you reconcile against, a page that quietly differs from the one you asked for is worse than a refusal.

Scope

The log is scoped to the calling key's organisation and environment. A test key never sees live verifications, and a live key never sees test ones. Anonymous verifications are attributable to no one and are not logged at all.