Rate Limit Error

[Rufaid786]

Select Topic Area

Question

Body

Hi team,
I’ve been using the GitHub Search/Commit and Search/Code REST APIs. Is it possible to use these APIs in a production application? We’re planning to build some apps where, whenever a user submits a query, we use these REST APIs to fetch content from GitHub.

According to the official documentation, one approach is to hold the response until the API rate limit resets, but this negatively impacts the user experience. We’re currently using a Personal Access Token (PAT) under an enterprise account, which i believe provides a limit of 5,000 requests per hour.

Are there any alternative suggestions for using these REST APIs in a production setup with a larger number of users?

[ArpanCodeX]

No, your current plan with a single Personal Access Token (PAT) will fail in production.

The Search API has a much stricter rate limit of 30 requests per minute. The 5,000 requests/hour limit you see is for the core API (like getting repo info), not for search. Your entire user base would share that tiny 30/minute limit, and your app would be rate-limited almost instantly.

Here are the correct solutions for a production app:

1. Build a GitHub App (Essential)
   This is the standard solution. Instead of one PAT, users install your GitHub App. The rate limit is then applied per-installation.

1 User: 30 requests/minute

1,000 Users: 30,000 requests/minute (30 for each user)

This allows your app to scale with your user base.

2. Implement Aggressive Caching
   You must cache search results. When a user searches for "my-function", store the result in a database like Redis for 5-10 minutes. If another user (or the same user) searches for the same term, you serve the cached result instead of hitting the GitHub API again. This drastically reduces your API calls.

[Rufaid786]

@ArpanCodeX Thanks for the reply.I think solution2 won't be helpful for my case as we have many users and the keyword they are searching will definitely vary time to time
For solution1--Do you have any reference/documentation on the same?My idea is to build an app that uses these Rest APIs to fetch relevant content.whenever user asks for a particular query ..,the app uses Rest APIs to search for the relevant content using keywords and respond back

[iyawnnn]

To build a production app using the GitHub Search/Commit and Search/Code REST APIs, you'll need to consider the rate limits, which are much stricter for search endpoints compared to other GitHub API operations. As you noted, the 5,000 requests per hour rate limit applies to core API endpoints (like repository data), but for the search API, the limit is only 30 requests per minute per Personal Access Token (PAT).

This means your current setup with a single PAT will likely fail in production once your user base grows, since the rate limit is shared across all users.

Here are the recommended solutions:

1. Build a GitHub App

• Instead of using a single PAT, you should build a GitHub App. GitHub Apps can be installed by multiple users, and the rate limit is applied per installation.
• For example, if 1 user installs your app, they get 30 requests/minute; if 1,000 users install your app, you get 30,000 requests/minute. This scales with your user base.

2. Aggressive Caching (for Varying Queries)

• Since your users' queries will vary over time, caching results for common searches can still help reduce the load on the GitHub API.
• You can store search results in a cache (e.g., Redis) and serve the cached results for repeat searches, especially for terms that are queried frequently.
• Even though caching might not help for every single query, it will significantly reduce the number of API calls for repeated queries.

[Rufaid786]

Hello thanks
Do you have any video link reference on the same?I was thinking how the authentication will be in that case?
Right now i just provided my PAT token in yaml file.But i was confused how the GitHub apps will be suitable in that case.Any link or reference is appreciated.Thanks

[murilochaves]

The rate limit for the Search API is much lower than for other GitHub operations. Using a single Personal Access Token (PAT) doesn’t work well as your number of users grows, because everyone shares the same limit of 30 requests per minute on that token.

For production applications, the best option is to build a GitHub App. Each installation of the app gets its own 30 requests per minute limit, so you can scale according to how many users install it.

It’s also helpful to use caching for repeated queries, even if it won’t cover every search your users make.

[Rufaid786]

My use case is that I’m planning to build an app that can query GitHub to fetch relevant information. The app is expected to be used at the organization level.
However, during beta testing, we are observing some rate-limit exceptions.

We installed a GitHub App as suggested and wrote scripts to generate a JWT token, then used that JWT to obtain an installation token. Using that installation token, we tried to call the rate-limit endpoint: https://api.github.com/rate_limit.

But I can see that there is no change in the remaining limit — it still shows 10:
"code_search": {
"limit": 10,
"used": 34,
"remaining": 10,
"reset": 1676644860
}
We just tried to see if we have enough rate limit before starting the implementation

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬