Skip to main content

​
Per key

  • Requests per second count all chains together: 10 rps on Standard is 10 per second in total, not per chain.
  • Requests open at once is per chain: a request counts from when it’s accepted until its response has been fully read. On pay-as-you-go it’s 1: finish reading one response before you send the next query to the same chain. On other plans it’s twice the requests-per-second limit, but at most 4 per chain for now, so that no single key can take all of a chain’s query capacity.
  • Every accepted response carries X-RateLimit-Limit (your requests per second) and X-RateLimit-Remaining (left in the current second).
Over a limit: Refused requests are free.
Honor Retry-After on every 429. A client that retries immediately in a tight loop turns rate_limited into key_blocked, which stops the key for 5 minutes on every chain.

​
Per client address

In front of the key checks, every route has limits per client IP address, keys or not: Normal clients never meet these. They exist to stop floods and key guessing.

​
Busy servers

When a chain’s server is at capacity, a request waits up to 5 seconds for a free slot, then gets 503 unavailable with Retry-After: 1. Retry with backoff. If you see it often, contact us.

​
Making the most of your limit

  • Large pages. Leave maxObjects at 100,000. One request then carries up to 100,000 rows; a rate of 1 per second still moves a lot of data.
  • Read responses promptly. A response you’re slow to read keeps one of your open-request slots busy.
  • Don’t poll faster than blocks arrive. See Following the head.
  • Serialize per key. With pay-as-you-go’s 1 request per second, run one query at a time per key. A simple client-side limiter (one request per second, sequential) never sees a 429.
  • Need more? Standard has 10 per second; custom plans can have more.

​
Checking your limits

GET /v1/account returns the key’s rps and status. It’s free and doesn’t count toward the limit.