Understanding GitHub API Rate Limits: REST, GraphQL, and Beyond

A deep dive into how API rate limits work on GitHub Enterprise Cloud, why they exist, and best practices for staying within the boundaries.

At GitHub, we strive to provide a reliable and performant API experience for every developer and organization. Whether you’re building automations, integrations, or developer tooling, understanding API rate limits helps ensure your apps run smoothly and fairly alongside millions of others.

In this post, we’ll walk you through the essentials of GitHub’s API rate limits for REST and GraphQL, and introduce the concept of secondary rate limits—what they are, why they matter, and how you can avoid running into them.

What are REST API Rate Limits—and Why Do We Have Them?

Every API request consumes resources on GitHub’s infrastructure. To ensure a responsive and stable service for all users, GitHub enforces rate limits—restrictions on how many requests you can make within a given time window.

How REST API Rate Limits Work

For most applications (including those using GitHub Enterprise Cloud), the REST API enforces a limit on the number of requests per hour per authenticated user or app. As of this writing:

• Authenticated requests: 5,000 requests per hour per user or OAuth app
• Unauthenticated requests: 60 requests per hour per IP address
• GHEC- org-owned GitHub Apps: 15,000 requests per hour per app

Each request you make, whether to fetch repositories, manage issues, or trigger workflows, counts towards your quota. You can check your current usage by inspecting the X-RateLimit-Remaining and X-RateLimit-Reset headers in API responses.

Why Do Rate Limits Exist?

Rate limits are essential for:

• Fairness: Ensuring all customers have equitable access to resources
• Reliability: Preventing accidental or intentional “denial of service” from runaway scripts or integrations
• Capacity Planning: Helping GitHub manage backend resources for a global audience

What To Do If You Hit the Limit?

If you exceed your limit, you’ll receive a 403 Forbidden error with a message indicating you’ve been rate limited. The best practice is to back off and retry after the reset time. Implementing exponential backoff and monitoring your app’s usage can help prevent disruptions.

**Pro tip: **Use conditional requests (via ETags) and pagination to minimize unnecessary calls.

What About GraphQL API Rate Limits?

GitHub’s GraphQL API enables more efficient, flexible queries—but it comes with a different approach to rate limiting.

Instead of counting requests, GraphQL rate limits are based on a cost calculation for each query, measured in “points.” The default limit is:

• 5,000 points per hour per user or app.
• 10,000 points per hour per org-owned GitHub App.

Each field in your query has a computational cost, so complex or deeply nested queries consume more points. The API response includes detailed rate limit info so you can track your usage.

Best Practices for GraphQL Rate Limits

• Optimize your queries: Request only the data you need
• Batch requests when possible: Instead of multiple calls, fetch related data in a single query
• Monitor cost: Use the rateLimit object in your queries to programmatically check your remaining quota

Introducing Secondary Rate Limits

In addition to primary rate limits, GitHub enforces secondary rate limits to protect the platform from sudden spikes, abusive patterns, or unexpected usage that could impact reliability.

What Triggers Secondary Rate Limits?

Secondary limits are more nuanced and can be triggered by:

• Making too many requests too quickly* (even if you’re below the primary limit)

• Repeatedly making the same request

• Patterns that indicate automation gone awry

  ** No more than 900 points per minute are allowed for REST API endpoints, and no more than 2,000 points per minute are allowed for the GraphQL API endpoint.*

Unlike primary limits, secondary rate limits are dynamic and may change based on current GitHub load or risk factors. When triggered, you’ll receive a 403 Forbidden response with a message indicating a secondary rate limit, and the affected requests may be temporarily blocked.

How to Avoid Secondary Rate Limits

• Spread out requests: Avoid bursting a large number of calls in a short time
• Cache data: Don’t poll the API for unchanged data
• Handle errors gracefully: Watch for secondary rate limit responses and implement retries with increasing delays

Recap and Resources

Understanding and respecting GitHub’s API rate limits is key to building robust, reliable integrations. Here’s a quick checklist:

• Monitor your current rate limit usage (headers and API responses)
• Use efficient, optimized queries—especially with GraphQL
• Back off and retry when rate is limited
• Design your apps to handle both primary and secondary rate limits gracefully

For more details, check out the official docs:

• REST API Rate Limits
• GraphQL API Rate Limits
• Secondary Rate Limits

Happy building! 🚀

Do you have questions or tips about working with API rate limits? Share your experience in the comments below!