How To Fix GitHub 429 Too Many Requests

1. What Causes the Error?	2. Step-by-Step Solution
3. Best Practices	4. Frequently Asked Questions

⚠️ GitHub 429 Too Many Requests means your Next.js 14/Node.js backend is sending too many GitHub API requests within a rate-limit window. Check the GitHub API rate-limit headers, authenticate requests, reduce duplicate calls, and add caching/backoff instead of repeatedly retrying immediately.

What Causes the "GitHub 429 Too Many Requests" Error?

GitHub returns a 429 Too Many Requests response when an API client exceeds an applicable request limit or is being temporarily throttled. Common causes include:

• Unauthenticated API requests: Requests may have lower limits than authenticated requests.
• Repeated server-side requests: A Next.js API route, Server Component, cron job, or backend function may call GitHub repeatedly.
• Missing caching: The same GitHub repository or user data gets requested on every page load.
• Aggressive retries: Retrying immediately after a failed request can make throttling worse.
• Multiple deployments or workers: Several Node.js processes can collectively generate a high request volume.

For a Next.js 14 + Node.js backend, this is primarily a server-side/API integration issue, although browser-side code can also trigger it when it communicates directly with GitHub.

Step-by-Step Solution: How to Resolve It

1. Authenticate GitHub API Requests

Use a GitHub token through an environment variable rather than making repeated unauthenticated requests. For example, in .env.local:

GITHUB_TOKEN=your_github_token

Do not expose this token through client-side JavaScript or commit it to Git.

2. Send the Token From Your Next.js Server

A basic server-side request can look like this:

❌ The Problematic Code

const response = await fetch(
  "https://api.github.com/repos/vercel/next.js"
);

const data = await response.json();

This request provides no authentication and can become problematic when your application sends it repeatedly.

✅ The Fixed Code

const response = await fetch(
  "https://api.github.com/repos/vercel/next.js",
  {
    headers: {
      Authorization: `Bearer ${process.env.GITHUB_TOKEN}`,
      Accept: "application/vnd.github+json",
    },
  }
);

if (!response.ok) {
  throw new Error(`GitHub API error: ${response.status}`);
}

const data = await response.json();

The important changes are:

• Authorization authenticates the API request.
• Accept explicitly requests GitHub's current JSON API representation.
• response.ok prevents the application from silently treating an error response as valid data.

3. Check GitHub's Rate-Limit Headers

Before adding retries, inspect the response headers.

const response = await fetch("https://api.github.com/repos/vercel/next.js", {
  headers: {
    Authorization: `Bearer ${process.env.GITHUB_TOKEN}`,
    Accept: "application/vnd.github+json",
  },
});

console.log("Remaining:", response.headers.get("x-ratelimit-remaining"));
console.log("Reset:", response.headers.get("x-ratelimit-reset"));

The x-ratelimit-remaining value helps determine how many requests remain for the applicable rate-limit bucket. The x-ratelimit-reset value provides the reset time as a Unix timestamp.

4. Do Not Retry 429 Immediately

A common mistake is creating an infinite or aggressive retry loop.

❌ Incorrect Retry Pattern

async function getGithubData() {
  const response = await fetch("https://api.github.com/repos/vercel/next.js");

  if (response.status === 429) {
    return getGithubData();
  }

  return response.json();
}

This can repeatedly hit the same endpoint while GitHub is throttling the client.

✅ Safer Retry Pattern

async function getGithubData() {
  const response = await fetch(
    "https://api.github.com/repos/vercel/next.js",
    {
      headers: {
        Authorization: `Bearer ${process.env.GITHUB_TOKEN}`,
        Accept: "application/vnd.github+json",
      },
    }
  );

  if (response.status === 429) {
    const retryAfter = response.headers.get("retry-after");

    if (retryAfter) {
      throw new Error(
        `GitHub rate limit reached. Retry after ${retryAfter} seconds.`
      );
    }

    throw new Error("GitHub rate limit reached.");
  }

  if (!response.ok) {
    throw new Error(`GitHub API error: ${response.status}`);
  }

  return response.json();
}

The key difference is that the application stops instead of immediately generating another request.

5. Cache GitHub Data in Next.js

If multiple users request the same GitHub data, caching can dramatically reduce unnecessary API calls. For example:

const response = await fetch(
  "https://api.github.com/repos/vercel/next.js",
  {
    headers: {
      Authorization: `Bearer ${process.env.GITHUB_TOKEN}`,
      Accept: "application/vnd.github+json",
    },
    next: {
      revalidate: 300,
    },
  }
);

const data = await response.json();

Here, revalidate: 300 tells Next.js to reuse the fetched data for a period instead of requesting the same GitHub resource for every request. For frequently accessed GitHub data, consider an application-level cache such as Redis or another shared cache when your deployment architecture requires it.

6. Reduce Duplicate API Calls

Check your application for patterns such as:

fetchGithub();
fetchGithub();
fetchGithub();

Also check:

• React components making duplicate requests.
• API routes called repeatedly by the frontend.
• Cron jobs running too frequently.
• Multiple server workers requesting identical data.
• Pagination loops that request unnecessary pages.
• Retry libraries configured with excessive attempts.

A single backend request can often serve multiple frontend consumers.

Best Practices to Prevent This Issue

• Cache identical GitHub API responses instead of requesting the same resource on every page request.
• Authenticate GitHub API calls and keep the token exclusively on the server.
• Respect rate-limit and retry information instead of using immediate recursive retries.
• Monitor x-ratelimit-remaining so your application can detect approaching limits before requests start failing.
• Request only the GitHub data your application actually needs and avoid unnecessary pagination or polling.

Frequently Asked Questions (FAQ)