You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have read and agree to the GitHub Docs project's Code of Conduct
What article on docs.github.com is affected?
Description
The GitHub REST API documentation page for search contains two contradictory statements about the rate limit for search requests on the same page:
Statement 1 — In the "About search" general section:
Unauthenticated requests are limited to 9 requests per minute
Statement 2 — In the "Search code" endpoint-specific section:
Rate limit: 10 requests per minute
These two values appear on the same documentation page (/en/rest/search/search) and directly contradict each other. Developers and AI agents reading this page cannot determine which rate limit to respect for GET /search/code.
Find the "About search" section near the top of the page
Note the rate limit stated there (9 requests per minute)
Scroll to the "Search code" endpoint section
Note the rate limit stated there (10 requests per minute)
Observe that both values appear on the same page and contradict each other
Expected Behavior
A single, consistent rate limit value for GET /search/code stated throughout the documentation page. If the rate limit differs between authenticated and unauthenticated requests, this should be clearly explained in both sections with the same values.
Actual Behavior
Two different values (9/min and 10/min) appear on the same page with no explanation of the discrepancy. It is unclear which is correct, whether one applies to authenticated vs unauthenticated requests, or whether one section is outdated.
Additional Context
For comparison, all other search endpoints are documented at 30 requests/minute — GET /search/code is the only endpoint with a lower limit, making this inconsistency more impactful for developers who rely on the documented value to throttle their requests
What part(s) of the article would you like to see updated?
he "About search" general section and the "Search code" endpoint-specific section both state the rate limit for GET /search/code, but with contradictory values (9 req/min vs 10 req/min respectively).
One of the following changes is needed:
Update the "About search" section to match the endpoint-specific value (10/min), OR
Update the "Search code" endpoint section to match the general section value (9/min), OR
If the difference is intentional (e.g., authenticated vs unauthenticated), add a clear explanation in both sections so the distinction is explicit rather than contradictory.
@mikejohnstonPremierinc That was not an easy term to search. Normally with auto-generated content it would be fixed internally, but since I'm not even sure whether the auto-generated section or the reference section is right, I need to work that out first. So I'm going to leave this open for now, until I know what I'm supposed to do with this.
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
@mikejohnstonPremierinc Got sidetracked about five different times today, but I finally tracked down where I asked about this and didn't hear anything. I've marked it for myself for next week, though, because I'm afraid I'm still not going to get answers on a Friday afternoon.
@mikejohnstonPremierinc Just to let you know where we're at with this, it looks like the 9/minute is correct (technically correct?) because (direct quote from an engineer, because I don't know what this means) "the rate limiter was changed to pre-count the request to avoid giving people extra requests." I think the team that owns the endpoint is looking into the changing the auto-generated portion, but I'm told it could be complicated to update. I will probably close this since it's being handled internally, but I'm going to leave it for a few more days just in case I hear something else that needs to go here for context.
Activity
khen90585-max commentedon Apr 18, 2026
Sharra-writes commentedon Apr 22, 2026
@mikejohnstonPremierinc That was not an easy term to search. Normally with auto-generated content it would be fixed internally, but since I'm not even sure whether the auto-generated section or the reference section is right, I need to work that out first. So I'm going to leave this open for now, until I know what I'm supposed to do with this.
github-actions commentedon Jun 8, 2026
A stale label has been added to this issue, because it has been open for 30 days with no activity. If you think this issue should remain open, please add a new comment.
Sharra-writes commentedon Jun 12, 2026
@mikejohnstonPremierinc Got sidetracked about five different times today, but I finally tracked down where I asked about this and didn't hear anything. I've marked it for myself for next week, though, because I'm afraid I'm still not going to get answers on a Friday afternoon.
Sharra-writes commentedon Jun 17, 2026
@mikejohnstonPremierinc Just to let you know where we're at with this, it looks like the 9/minute is correct (technically correct?) because (direct quote from an engineer, because I don't know what this means) "the rate limiter was changed to pre-count the request to avoid giving people extra requests." I think the team that owns the endpoint is looking into the changing the auto-generated portion, but I'm told it could be complicated to update. I will probably close this since it's being handled internally, but I'm going to leave it for a few more days just in case I hear something else that needs to go here for context.
look commentedon Jul 10, 2026
I have fixed the underlying problem and the rate limit is now correctly charged at 10 requests per minute. This issue can now be closed.