List pagination¶

How e10s list endpoints work when they paginate.

Catalog lists (features, plans), entitlements, check, overrides, members, and keys are get-all. Do not paginate those.

Query¶

Param
`limit`	Optional. Default 50, max 100. Over-max is clamped, not 422. `< 1` or non-integer → 422 `VALIDATION_ERROR`.
`starting_after`	Optional. Exclusive cursor: the `id` of the last item on the previous page. Omit on the first page.

No offset. No page. No ending_before.

starting_after must be a well-formed id for that collection. Invalid → 422 VALIDATION_ERROR (fallback sentence). A well-formed id that is not in the collection is not an error — the walk continues after that point in id order.

Order¶

Always id ascending. No other sort.

Subscriber id is the id you chose (lexicographic). Subscription id is a ULID (time-sortable).

Body¶

{
  "subscribers": [ ... ],
  "has_more": false
}

Field
named collection	Plural resource key (`subscribers`, `subscriptions`). Not `data`.
`has_more`	`true` if another page exists. Always present.

When has_more is true, pass the last item’s id as starting_after on the following request. Do not send starting_after when has_more is false.

No cursor field in the body. No total. limit is not echoed.

Paginated lists¶

GET …/subscribers
GET …/subscribers/{subscriber_id}/subscriptions

Stop¶

Do not add offset
Do not add a cursor field on the list object (last, next, next_cursor)
Do not add bidirectional cursors
Do not paginate features, plans, entitlements, check, overrides, members, or keys
Do not use page + limit