GitHub API Rate Limits Explained
Comprehensive guide to GitHub REST and GraphQL API rate limits. Learn about authenticated vs unauthenticated limits, secondary rate limits, and optimization strategies.
API Limits
Detailed Explanation
GitHub API Rate Limits
GitHub enforces rate limits on both its REST API and GraphQL API. Understanding these limits is essential for building reliable integrations.
REST API Limits
| Authentication | Limit | Window | Per-Second Avg |
|---|---|---|---|
| Unauthenticated | 60 | Per hour | 0.017 |
| Personal token | 5,000 | Per hour | 1.39 |
| GitHub App | 5,000 | Per hour | 1.39 |
| GitHub App (installation) | 5,000+ | Per hour | 1.39+ |
GraphQL API Limits
The GraphQL API uses a point-based system rather than a simple request count:
- 5,000 points per hour per authenticated user
- Each query has a calculated cost based on the nodes requested
- A simple query might cost 1 point, while a query requesting 100 repository objects could cost 101 points
Secondary Rate Limits
Beyond the primary rate limits, GitHub enforces secondary limits:
- No more than 100 concurrent requests
- No more than 900 points/minute for REST API content creation (POST, PATCH, PUT, DELETE)
- No more than 80 content-generating requests per minute (via the GraphQL API)
Checking Your Rate Limit Status
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4987
X-RateLimit-Reset: 1706140800
X-RateLimit-Used: 13
X-RateLimit-Resource: core
Optimization Strategies
- Use conditional requests with
If-None-Match(304 responses don't count against your limit) - Use GraphQL to fetch only the data you need in a single request
- Implement webhook listeners instead of polling
- Cache responses using
ETagheaders
Use Case
You are building a GitHub integration that monitors 200 repositories for new pull requests. Each repository check requires 2 API calls. You need to design a polling strategy that stays within the 5,000 requests/hour limit while keeping latency under 5 minutes.