Our API employs a number of safeguards against bursts of incoming traffic to help maximize its stability. Users who send many requests in quick succession may see error responses that show up as status code 429.
We have implemented the following limits:
A rate limiter that limits the number of requests received by each API client within any given minute. Current values are 1000 requests per minute.
A rate limit that limits the number of times that a user connection can be synced using the POST /sync endpoint. Current value is once every 5 seconds.
Treat these limits as maximums and don’t generate unnecessary load. We may adjust limits to prevent abuse or enable well-behaved high-traffic applications.
Should we decide the requirement to change the above value of 1000 requests per minute we will communicate this ahead of the change
Currently there is no limit when initiating a connection or initiating a payment.
The limits only apply to the calls done to our Data API
Responding to rate limiting conditions
If you exceed a rate limit when using any of our HTTP-based APIs, we will return a HTTP 429 Too Many Requests error, and a Retry-After HTTP header containing the number of seconds until you can retry.
For example, if your app exceeds the rate limit of GET /transactions, you might receive a raw HTTP response like this:
HTTP/1.1 429 Too Many Requests Retry-After: 30 X-RateLimit-Limit: 1000 X-RateLimit-Remaining: 0 X-RateLimit-Reset: 2021-02-11T10:45:16.848Z
This response instructs your app to wait 30 seconds before attempting to make the same call.
By evaluating the Retry-After header you can wait for the indicated number of seconds before retrying the same request.
At any point you can inspect the
X-RateLimit-Limit header which indicates the current limit that your API client has and the
X-RateLimit-Remaining header with the remaining calls.
Updated about 2 years ago