Pagination

Every list endpoint takes the same two query parameters and returns the same shape.

curl "https://api.pealboard.com/v1/issues?limit=50" \
  -H "Authorization: Bearer pb_AbCdEf0123456789AbCdEf0123456789AbCdEf01"

{
  "data": [ { "...": "one issue" } ],
  "nextCursor": "MDAwMS0y"
}

The parameters

Parameter	Meaning
cursor	The previous page’s nextCursor, sent back unchanged. Omit it to start at the beginning.
limit	How many rows to return. Defaults to 50, at most 100.

nextCursor is null on the last page. Fetch the next page by sending it back as cursor, unchanged:

curl "https://api.pealboard.com/v1/issues?cursor=MDAwMS0y&limit=50" \
  -H "Authorization: Bearer pb_AbCdEf0123456789AbCdEf0123456789AbCdEf01"

A cursor is opaque — base64url text encoding the sort key’s own components, not a page number or an offset — so it stays valid while new rows are being added ahead of it and a caller cannot construct one by hand. A malformed or foreign cursor is 422 invalid_request, never a database error. Ordering is always by the sort key and then by id, so a page never repeats a row or skips one.

updated_since, for polling a window of change

GET /v1/issues also takes updated_since, either an ISO 8601 instant or a window relative to now:

curl "https://api.pealboard.com/v1/issues?updated_since=-1h&limit=100" \
  -H "Authorization: Bearer pb_AbCdEf0123456789AbCdEf0123456789AbCdEf01"

Form	Example
An ISO 8601 instant	2026-09-09T20:00:00Z
A relative window	-7d, -24h, -2w

Combine it with cursor and limit the same way as any other list: a caller polling for change fetches updated_since=<the last time it checked> and pages through everything newer, then records the time it checked for next time. See Webhooks for why polling, not a push, is how a caller learns about change in v1.