How to fix 429 Too Many Requests on RPC endpoints
A 429 status code means your application has exceeded the rate limit set by an RPC provider. This happens frequently during NFT mints, token launches, or any high-volume event where many requests fire simultaneously. The error is not a bug - it is a deliberate protective mechanism.
Providers like Infura and Alchemy enforce these limits to prevent a single user from degrading service for everyone else. Free tiers are especially restrictive. Infura’s free plan allows 100,000 requests per day for Ethereum mainnet. Alchemy’s free tier caps at 300 compute units per second. Both numbers are as of this writing. A single dapp during a popular mint can exhaust those allocations in minutes.
How compute unit pricing works
Alchemy charges requests based on compute units, not raw call count. A simple eth_blockNumber costs 2 units. A complex eth_call that touches many storage slots can cost 640. The free tier’s 300 CU/second ceiling means heavy contract interactions hit the limit fast. Infura uses a straight request-per-second model, but both providers apply separate limits for different API methods.
Rate limits apply per API key. If you use the same key across multiple frontends or background services, they share the same bucket. That is why a wallet extension and a dashboard running on the same key can trip the limit without either one appearing excessive individually.
Practical solutions
The simplest fix is upgrading to a paid plan. Infura’s Growth tier starts at $50/month and raises the daily cap to 500,000 requests. Alchemy’s Growth plan at $49/month increases the compute unit limit to 1,500 CU/second. These numbers are approximate but give a clear comparison. For production dapps, this is often the cheapest option compared to engineering time spent on workarounds.
But a paid plan is not infinite. Traffic spikes can still overwhelm it. That is where retry logic matters.
Implement exponential backoff
When your application receives a 429, it should not immediately retry. That only guarantees another 429. Exponential backoff means waiting 1 second, then 2, then 4, then 8 - up to a maximum delay like 30 seconds. Each attempt multiplies the wait time. Many HTTP libraries support this natively; for example, the fetch API in JavaScript can be wrapped with a retry helper that respects the Retry-After header some providers include.
Use batch requests
Infura and Alchemy both support JSON-RPC batch calls. Instead of sending 50 individual eth_call requests, you bundle them into a single HTTP POST with an array of request objects. The provider processes them as one request against your rate limit, dramatically reducing the number of API calls during operations like reading token balances for a list of addresses.
Set up multi-provider failover
One provider’s rate limit should not take down your entire application. Configure a primary provider and a secondary fallback. If the primary returns a 429, the application switches to the secondary for that request. This can be done with a simple round-robin strategy or weight-based routing. Libraries like ethers.js support multiple providers natively. The pattern is: try provider A, catch 429, try provider B, catch 429, then wait and retry both.
WebSocket subscription limits
Rate limits for WebSocket connections work differently from HTTP requests. Providers allow a limited number of simultaneous WebSocket subscriptions. Infura permits 10 concurrent subscriptions per project on free plans; Alchemy allows 25 subscriptions per app on free tiers. Exceeding these limits disconnects the client.
The fix is to consolidate subscriptions. Instead of subscribing to every token transfer individually, use a single subscription with filters. Or poll via HTTP at intervals rather than maintaining a persistent WebSocket stream for each event. WebSocket reconnection logic should include a backoff - immediate reconnection after a rate-limit disconnect will fail again.
Monitor and adjust
Rate limits change. Providers update their pricing and caps without notice. Monitor your application’s error rates and adjust your approach when patterns shift. The 429 error is a signal that your architecture needs scaling, not a problem to brute-force through. Respect it, plan for it, and your dapp will survive the next mint without crashing.
Not financial advice. starname.me publishes market data and general information about digital assets. Crypto assets are volatile and you can lose everything you put in. Nothing here is a recommendation to buy, sell or hold, and we make no price predictions.
Prices are sourced from third parties and may be delayed or wrong. Verify anything you intend to act on against a primary source.