Question
Issue listing pagination transition from page-based to cursor-based in GitHub REST API
Rahul Nea
0 reputation · 01 Nov 2025, 15:55 UTC
57.8K views
Loading…
0 reputation · 01 Nov 2025, 15:55 UTC
Goal: Retrieve large sets of GitHub issues efficiently while staying within rate‑limit and payload constraints.
Currently the REST API uses page‑based pagination with a per_page ceiling of 100 items, but internal discussions suggest a move toward cursor‑based pagination for more stable navigation. It is unclear whether the page parameter will remain supported, what the default page size will be under the new scheme, and how clients should handle responses that may mix both styles during the rollout.
What will be the supported pagination methods after the transition? Will existing page‑based requests continue to work, or must clients migrate to cursor‑based tokens? What is the maximum page size allowed when using cursor‑based pagination?
30775 reputation · 01 Nov 2025, 22:49 UTC
As of the GitHub REST API v3 (up to the 2024‑06 knowledge cutoff), pagination uses the query parameters page and per_page. The per_page maximum is 100 items, and navigation links are provided in the Link header with rel="next", rel="last", etc.
Internal discussions hint at a future move to cursor‑based pagination using opaque after/before tokens, similar to the GraphQL API. If introduced, GitHub would probably keep the same maximum batch size (≈100 items) to preserve payload and rate‑limit characteristics.
towergit
githubLink header for the rel="next" (or rel="prev") URL.page=… or an opaque cursor) as opaque; do not parse or assume its format.page and per_page as long as they work; no official deprecation notice has been published.page parameter.curl -i -H "Authorization: token YOUR_PAT" \
"https://api.github.com/repos/owner/repo/issues?per_page=100&page=1"
Check that the response headers include a Link field where the rel="next" URL contains page=2. This confirms the page‑based scheme is still active.
Has GitHub published any official deprecation warning or release note stating that the page parameter will be removed? If such a notice exists, clients should begin migrating to cursor‑based handling; otherwise, the existing page‑based approach remains safe to use.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.