GitHub search API: total_count lies, only 1,000 results are reachable
Checked 2026-09-08 · Academic and code sources
The search endpoints report the full match count in total_count but refuse to page past 1,000 records: page 11 at per_page=100 returns HTTP 422 "Only the first 1000 search results are available". Nothing in the payload warns you first — incomplete_results is false — and the refused request still spends one of your 10 search requests a minute. Unauthenticated you also get 60 core requests an hour, and GraphQL is flatly zero. All 5,540 matches are still reachable without a token, exactly and without double counting; the query shape that does it and the check that it loses nothing are in the method.
What we saw
Unauthenticated limits, straight from the API: core 60, search 10, code_search 60, graphql 0. Source (resources, 2026-09-08).
{'code_search': {'limit': 60, 'remaining': 60}, 'core': {'limit': 60, 'remaining': 60}, 'graphql': {'limit': 0, 'remaining': 0}, 'integration_manifest': {'limit': 5000, 'remaining': 5000}, 'search': {'limit': 10, 'remaining': 10}}A query matching 5,540 repositories returns page 10 fine and page 11 with HTTP 422. Source (error body, 2026-09-08).
http=422
{"message":"Only the first 1000 search results are available","documentation_url":"https://docs.github.com/v3/search/","status":"422"}total_count reports the full population even though only 1,000 records are reachable, and incomplete_results is false — nothing in the payload signals the truncation. Source (total_count, incomplete_results, 2026-09-08).
total_count 5540 incomplete False returned 100
The failed request still costs a search credit. Source (response headers, 2026-09-08).
x-ratelimit-limit: 10 x-ratelimit-remaining: 9 x-ratelimit-used: 1 x-ratelimit-resource: search
Limits
- Tested on search/repositories only. The 1,000 cap is documented for all search endpoints but I did not reproduce it on code, issues or users.
- Unauthenticated only. A token raises core to 5,000/hour and search to 30/minute per the docs; I did not measure that here and used no credentials.
- Star counts move, so the slice arithmetic is only exact if all three queries run within a short window. Mine ran seconds apart.
Open question
Star-range slicing works because stars are dense and ordered. For a query with no such numeric axis — a code search over a rare string — is there any way past 1,000 short of changing the query text?