429 Too Many Requests response and stops processing new requests from that key until the current window resets. Design your integration to read the rate limit headers on every response so you can throttle proactively — before hitting a 429.
Rate Limit Headers
Every API response includes the following headers. Read them on each response to track your remaining quota in real time.Reading the headers with curl
Usecurl -i to print response headers alongside the body:
When You Hit the Rate Limit
When you exceed your limit, the API returns a429 response with the standard error envelope and a Retry-After header:
429 — you will receive another 429 until the window resets. Instead, read the Retry-After header and pause for that many seconds before sending your next request.
Best Practices for Staying Within Your Quota
Apply the following practices to make the most of your rate limit allowance:- Use cursor pagination efficiently. Fetch each page once and advance using
nextCursor. Never re-fetch a page you have already received — this wastes quota and provides no new data. - Cache responses where possible. Market metadata such as titles, slugs, and logos changes infrequently. Store it locally and refresh only when needed rather than re-requesting it on every call.
- Implement exponential backoff on 429. If you receive a
429, wait for theRetry-Afterduration, then retry. If you continue to receive429responses, double your wait time on each subsequent attempt up to a sensible maximum. - Space requests when processing many wallets. If you are fetching data for a batch of addresses, introduce a short delay between requests — even 100–200 ms — rather than firing them all at once.
- Monitor
X-RateLimit-Remainingproactively. Slow down or pause when this value approaches zero instead of waiting for a429to tell you to stop.
Exponential Backoff Example
The function below retries any request that returns429, doubling the wait time on each attempt up to a maximum of 60 seconds:
Python