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

  1. Use conditional requests with If-None-Match (304 responses don't count against your limit)
  2. Use GraphQL to fetch only the data you need in a single request
  3. Implement webhook listeners instead of polling
  4. Cache responses using ETag headers

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.

Try It — Rate Limit Calculator

Open full tool