How to Fix RPC 429 Too Many Requests Errors

What an RPC 429 error means

HTTP 429 Too Many Requests is a rate-limit response. A blockchain RPC provider can apply limits by API key, account, IP address, method, network, request unit, or time window. A burst can therefore trigger 429 responses even when the daily request total looks low.

Treat the response as a capacity signal rather than a transient network failure. Retrying every failed request immediately increases the same burst that caused the limit and can extend the incident.

Diagnose the limiting scope first

Check the provider dashboard and response headers before changing application code. Record which network, JSON-RPC method, endpoint, region, and API key produced the error. Compare the failure time with deployment events, indexer backfills, traffic spikes, and scheduled jobs.

• Confirm whether the limit is measured in requests, response units, compute units, or concurrent connections.
• Separate sustained traffic from short bursts; each needs a different control.
• Identify expensive methods such as wide eth_getLogs ranges, trace calls, or historical-state queries.
• Check whether several services share the same API key or public endpoint.
• Inspect Retry-After and provider-specific rate-limit headers when they are available.

Retry safely with exponential backoff and jitter

Retry only idempotent read requests automatically. Increase the delay after each failed attempt and add random jitter so multiple workers do not retry at exactly the same moment. Keep a maximum attempt count and surface a controlled error when the budget is exhausted.

async function rpcRequest(url: string, body: unknown) {
  const maxAttempts = 5;

  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const response = await fetch(url, {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify(body),
    });

    if (response.ok) return response.json();
    if (response.status !== 429) throw new Error(`RPC failed: ${response.status}`);

    const retryAfter = Number(response.headers.get("retry-after"));
    const exponentialDelay = Math.min(500 * 2 ** attempt, 10_000);
    const jitter = Math.floor(Math.random() * 250);
    const delay = Number.isFinite(retryAfter)
      ? retryAfter * 1000
      : exponentialDelay + jitter;

    await new Promise((resolve) => setTimeout(resolve, delay));
  }

  throw new Error("RPC rate limit retry budget exhausted");
}

Reduce avoidable RPC traffic

Retries protect a short-lived burst, but they do not solve sustained overuse. Reduce the number and cost of requests before raising capacity.

• Cache stable results such as chain IDs, token metadata, finalized blocks, and contract configuration.
• Deduplicate identical in-flight requests so concurrent users share one upstream call.
• Batch compatible JSON-RPC reads when the endpoint supports batching.
• Use WebSocket subscriptions for live events instead of polling every block from every client.
• Split large eth_getLogs ranges into bounded windows and checkpoint completed ranges.
• Limit worker concurrency with a queue or token bucket instead of starting every job at once.

Design for production capacity

A production RPC client should combine timeouts, bounded retries, concurrency limits, caching, and observability. Track 429 rate, latency, error rate, request units, method distribution, and queue depth. Alert before the application reaches a hard capacity ceiling.

Keep development, staging, backfill, and production workloads on separate keys or endpoints. This prevents a historical-data job from exhausting capacity required by user-facing traffic. For critical applications, use a managed endpoint with measurable limits and a clear path to dedicated infrastructure.

When to increase RPC capacity

Increase capacity when optimized traffic consistently approaches the plan limit, user-facing latency grows behind a queue, or essential methods consume more units than a shared plan can provide. OnFinality offers managed RPC endpoints with request analytics and dedicated node options for workloads that need isolation.

Compare current RPC plans at /pricing/rpc, explore supported networks at /networks, or create an endpoint through the OnFinality API service.