Skip to main content
This guide explains GitHub API rate limiting: what limits exist, how to check your current usage, and tips to avoid throttling. It covers both primary and secondary limits, how to authenticate to raise limits, and example API calls (with curl) for checking limits, reading repository contents, and listing Actions workflow runs. GitHub enforces two classes of rate limits: primary and secondary. Primary rate limits define how many requests a client (by IP, app, or user) can make over a time window:
  • Unauthenticated requests (no token): 60 requests per hour (attributed to the originating IP).
  • Authenticated requests using a personal access token (PAT): 5,000 requests per hour (per user/token).
  • GitHub Apps: higher limits (example: ~15,000 requests per hour depending on context).
A dark-themed screenshot of the GitHub Docs site showing REST API documentation about rate limits. The left sidebar navigation is visible and the main content explains primary rate limits for authenticated and unauthenticated users.
Secondary rate limits protect GitHub’s availability by detecting abusive or excessive usage patterns. These can be triggered by many concurrent requests, bursts of expensive operations, or too many requests per minute and are enforced even if you are within the primary limit.
A dark‑mode screenshot of the GitHub Docs page titled "About secondary rate limits," showing the left navigation menu and the main article text describing API rate limit rules and limits.

Quick reference — primary limits

How to check your current rate limit

  • Rate limits are returned in response headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Reset, and X-RateLimit-Resource.
  • You can also query the REST endpoint GET /rate_limit to receive the same information in JSON form.
Example: check rate limits (unauthenticated) with curl:
Example JSON response (abridged; unauthenticated):
Response headers also include the X-RateLimit-* fields so you can programmatically inspect and throttle clients or surface usage dashboards.

What each X-RateLimit-* header means

Using a Personal Access Token (PAT)

Authenticate requests with a PAT to increase the core limit (commonly from 60 to 5000 per hour). Create a token in GitHub: Developer settings → Personal access tokens. Then include it in the Authorization header. Example (authenticated request):
Replace YOUR_TOKEN with a securely stored token (do not hard-code tokens in source control or logs).
If you need access to private repository data, ensure your token has the required scopes (for example, repo). For organization repos protected by SAML single sign-on, grant your token access to the organization through your identity provider; otherwise requests will return a 403 with SAML enforcement instructions.

Fetching repository contents

To fetch a file’s contents from a repository, call the repository contents endpoint with the owner, repo, and path:
Notes:
  • Wrap placeholder values like OWNER, REPO, PATH, and YOUR_TOKEN in backticks when editing MDX.
  • For private repositories, omitting Authorization often returns 404 Not Found (GitHub hides the existence of private repos) or 401 Unauthorized/Bad credentials for invalid tokens.
Example error when credentials are invalid:
Example successful response (abridged). The file content is Base64-encoded in the content field:
Decode Base64 locally:

Using the Actions REST API — listing workflow runs

To list workflow runs for a repository:
Organization-level protections:
  • If your token lacks organization access (for example, SAML SSO not authorized), GitHub returns a 403 Forbidden with an explanation and instructions to grant token access.
Example SAML enforcement error:

Best practices and next steps

  • Monitor usage programmatically using the X-RateLimit-* headers or the /rate_limit endpoint.
  • Reduce polling frequency and avoid aggressive loops.
  • Use conditional requests (ETags / If-None-Match) to avoid downloading unchanged resources.
  • Implement exponential backoff and retry on 429 Too Many Requests or secondary-rate-limit responses.
  • Cache common responses where feasible.
  • For organization data, ensure your token is authorized with appropriate scopes and SAML access if enforced.
Best practice: cache responses, use conditional requests with ETags, and implement exponential backoff on 429/secondary-rate-limit responses to reduce the likelihood of hitting secondary limits.

Watch Video