Rate Limits

Learn about the Blockchain.com Pay rate limits and how to handle them

At Blockchain.com, we are committed to offering a reliable and stable API experience. To ensure our API remains available to all users, we have implemented rate limiting to prevent excessive traffic that could otherwise impair system performance. Rate limiting aids in:

• Protecting our infrastructure from being overwhelmed.

• Ensuring a fair distribution of resources among all users.

• Maximizing the overall stability and performance of the Blockchain.com Pay API.

Handling Rate Limits

Clients who make rapid or consecutive API requests might encounter error responses indicated by a HTTP status code 429. Encountering this status code signals that you have hit our rate limit and your systems should adjust their request rate.

A common strategy to handle rate limiting is to implement a retry mechanism. In the events of a 429 status codes, your system should retry the request, but follow an exponential backoff schedule. This strategy reduces the request frequency when faced with rate limit constraints.

Rate Limit Categories

We rate limit the Blockchain.com Pay API endpoints based on authentication method.

Public Authentication Rate Limiting

This authentication strategy is typically used for endpoints consumed in your clients' browser, and require only the X-Public-API-Key for access. If you are consuming the endpoints in your backend systems, consider using Private Authentication strategy. This way you'll benefit from higher rate limits and enhanced security.

Rate Limit: Up to 10 requests per second, per IP address.

Once an individual IPv4 address or IPv6 /64 IP range exceeds the rate limiting threshold, further requests to the origin server are blocked with an HTTP 429 response status code. The response includes a Retry-After header to indicate when the client can resume sending requests.

Private Authentication Rate Limiting

This type of authentication is used in environments where you can securely distribute the private API keys, and it allows for higher rate limiting thresholds. To use this rate limiting strategy, all requests hitting the API must contain both the X-Public-API-Key and X-Private-API-Key headers.

Rate Limit: Up to 100 requests per second, for all API keys across your organization

Once your organization exceeds the rate limiting threshold, further requests will be blocked with an HTTP 429 status code. The response includes a Retry-After header to indicate when you can resume sending requests.

Always handle your private API keys securely and never expose them publicly. This authentication mechanism is not suitable for code running on the client side.

Summary

By understanding and adhering to our rate limits, you can ensure optimal performance for your application and prevent unnecessary interruptions. Always monitor your request rates and implement smart retry mechanisms for the best results. If you have further questions or require assistance, please reach out to our support team.