Pagination & limits

Cursors, date ranges and rate limits.

Cursor pagination

List endpoints accept limit and cursor. The default page size is 50; the maximum is 100. Read page.nextCursor and stop when it is null.

{
  "data": [],
  "page": {
    "nextCursor": null,
    "hasMore": false
  },
  "meta": {
    "requestId": "example-request-id",
    "generatedAt": "2026-09-04T12:00:00.000Z"
  }
}

Pass the cursor back unchanged. Preserve all filters between requests. Cursors represent positions, not a frozen dataset: ingestion can add or change records while you paginate.

Ordering

Schedule windows

Choose either localDate or a timestamp range using startsFrom and startsBefore. Do not combine them. The lower bound is inclusive and the upper bound is exclusive.

The configured maximum public schedule range is 31 days. For broad current queries, omitting both bounds starts the range at request time. Broad archived/all queries require explicit dates. Specific Release Showings return the paginated run without dates; optional dates narrow it. If one is omitted, the server supplies a 31-day window. Send explicit bounds on every page to keep that window stable.

?startsFrom=2026-09-04T00%3A00%3A00Z
&startsBefore=2026-09-05T00%3A00%3A00Z
&limit=50

Broad Showing, calendar announcement and country Release lists default to scope=current. Select scope=archived for published history, or scope=all when your question needs both. Current means the data still belongs to the active store, including finished runs awaiting archive publication; dates do not determine ownership. Archived/all requires history:read. Preserve scope between pages. Existing historical integrations must explicitly add archived or all.

Use /v1/releases/{id}/showings for one complete country run. The URL and Release ID remain stable after archival; the service follows its owner automatically. A failed archive read returns an error instead of partial history.

Rate limits

The configured contract allows 300 authenticated requests per organization per minute, with a separate pre-authentication limiter of 120 attempts per client address per minute. Keys and sessions for an organization share the same counter. The pre-authentication limit also applies to valid credentials, so a single client address can reach its limit first.

On 429, respect Retry-After: 60. Counters are local to a Cloudflare location and eventually consistent. This is abuse protection, not an exact global quota or a service-level guarantee. Cloudflare rate-limit behavior ↗