Numbered Pager

For APIs that page by index — anything accepting a page parameter. RMS list endpoints gained 0-based page in RMS-1479, so this is the default pager for RMS grids; reach for Cursor Pager only where paging is an opaque forward-only token.

Props

Two ceilings, and the lower one wins

The pager never offers a page the API would reject. Two independent limits apply:

When the depth cap binds first, the remaining rows are genuinely unreachable by page number and the pager says so. Asking past maxSkip returns 400 invalid_page and is never clamped — a clamped offset would land off a page boundary, so a silently-adjusted page would show the wrong rows rather than an error.

Each endpoint publishes its own maxSkip in its OpenAPI page description. Pass it in; don't hard-code a page count.

pageSize comes from the response, not the request

Bind pageSize to the envelope's pageSize — the size actually served. An over-large request is clamped server-side, so using the value you sent computes the page count from a denominator the server never used, and the grid renders pages that do not exist.

totalSize: null means "not calculated"

The server computes an exact totalSize in offset mode and never on a cursor walk. null is therefore "not counted", not "no rows" — the pager shows a range without a total rather than claiming zero. There is no includeTotal parameter to opt into; RMS-1479 retired it because the navigation mode already determines the answer.

Do / Don't

• Do keep page 0-based end to end — it matches TanStack Table's pageIndex and the API's own parameter, so no off-by-one lives between grid, URL and request.
• Do reset to page 0 whenever a filter, sort or page size changes. The offset refers to a result set that no longer exists.
• Don't derive the page count from a total the server did not return.
• Don't use this for a cursor API — without a page index, numbered navigation is an offer the server cannot honour.