The CDP API enforces rate limits to ensure fair usage and system stability. Rate limits are calculated using rolling 10-second windows and are applied separately for read and write operations.
Operation Type | Rate Limit | Time Window |
---|---|---|
Write APIs | 500 requests | 10 seconds |
Read APIs | 600 requests | 10 seconds |
Write operations include any API endpoints that modify resources (POST
, PUT
, DELETE
methods). These are limited to 50 requests per 10 seconds.
Read operations include any API endpoints that retrieve data (GET
methods). These are limited to 250 requests per 10 seconds.
When you exceed the rate limit, the API will respond with a 429
(“Too Many Requests”) status code. The response will include an error object with details about the rate limit violation:
To effectively work with these rate limits, consider implementing the following best practices:
You should implement an exponential backoff strategy to handle rate limit errors.
More on exponential backoff
Exponential backoff is a strategy used to retry requests after a failure, increasing the delay between retries each time. This is especially useful for rate limits and temporary server errors.
Caching improves performance and reduces unnecessary load on your server or APIs. You should:
Instead of making many individual requests, combine them into a single call and use bulk endpoints when possible.
Given our rate limit structure, you should track your API usage to stay within limits, and set up alerts before reaching rate limit thresholds.
Consider the following when designing your application around rate limits:
If you consistently hit rate limits and need higher limits for your use case, please reach out to us in the #wallet-api channel of the CDP Discord to discuss your requirements.