Avoid rate limiting

Infura rate limiting

Infura applies rate limiting account-wide after exceeding the daily request limit.
For rate limiting designed to protect our service in the event of an attack, Infura uses a combination of:
  • Source IP address.
  • JSON-RPC method.
  • Project ID.
Infura is constantly adjusting rate limits based on overall usage and possible abuse.
Typically only aggressive use should experience rate limiting.
Customers running into rate limits are encouraged to contact us. We'll work with you to determine how best to avoid rate limits.
Requests for archive data are more expensive and are therefore subject to different rate limits. Find out more.

Noticing rate limiting behavior

When you are rate limited, your JSON-RPC responses have HTTP Status code 429.
They also contain a JSON-RPC error response. For example:
1
{
2
"jsonrpc": "2.0",
3
"id": 1,
4
"error": {
5
"code": -32005,
6
"message": "project ID request rate exceeded",
7
"data": {
8
"see": "https://infura.io/docs/ethereum/jsonrpc/ratelimits",
9
"current_rps": 13.333,
10
"allowed_rps": 10.0,
11
"backoff_seconds": 30.0,
12
}
13
}
14
}
Copied!
The data array contains three fields regarding rate limits:
  • current_rps: the current rate per second determined by Infura.
  • allowed_rps: the current allowed rate which you should stay under.
  • backoff_seconds: the suggested amount of time to wait before sending more requests.
The value for allowed_rps changes with regards to the overall network conditions; therefore consider the value for current_rps valid and up-to-date.

Tips to avoid rate limiting

We recommend pausing JSON-RPC activity for the time value in backoff_seconds
If you are consistently rate limited, consider these work-arounds:
  • Cache Ethereum data locally. Barring exceptionally rare deep reorganizations of the chain, blocks more than a couple of blocks below the head of the chain can be cached indefinitely. Ask for the data once then keep it locally.
  • Limit RPCs at DApp startup. Likewise, limit the number of RPCs your DApp calls immediately at startup. Only request data as the user accesses that portion of the DApp, and cache anything from older blocks for next time.
  • Don't poll Infura in a tight loop. New blocks come roughly every 15 seconds, so requesting new data at a faster rate usually doesn't make sense. Consider using eth_subscribe to be notified when new blocks are available.