As you develop your integration, it's important to consider the rate limits Finix has in place.
A rate limit, in simplest terms, limits the number of API requests you can make in any given period. Rate limits play a crucial role in ensuring the stability and performance of an API.
It's important to keep rate limits in mind while developing your integration and making sure your application doesn't programmatically create unnecessary requests.
info
Finix can change limits to prevent abuse or enable high-traffic applications. If your requests are being rate limited, reach out to your Finix point of contact or email the Finix Support team.
By controlling the number of requests your application makes, you can avoid hitting these limits and keep the performance of your application consistent and stable.
Production Rate Limits
Our standard production rate limits are the following:
- 100 Writes/second
- 100 Reads/second
If you require a higher rate limit, please reach out to Finix Support. We can configure these rate limits to your business needs.
Sandbox Rate Limits
We also have Sandbox Rate Limits that apply for Writes and Reads. These rate limits are subject to change and are not publicly documented at this time.
Exceeding Rate Limits
Rate limited requests return a 429 HTTP Error. If a 429 HTTP Error is returned, your application won't be able to get the data it needs from responses to process transactions.
See Handling Rate Limits for tips on how to develop your application to work within these limits and handle 429 HTTP Errors.
If you suddenly see a rising number of requests get rate limited, please reach out to Finix Support.
Handling Rate Limits
To avoid running into rate limits, optimize your application so it makes the least amount of requests needed. By optimizing your code and monitoring usage, you can develop an application that's both efficient and effective.
Here are some ways you can can prevent your application from being rate limited:
Exponential Backoff
To handle 429 errors, retry requests using an exponential backoff strategy. Using exponential backoff will gradually increase the time between retries until your requests are no longer being rate limited.
Cache Response
Caching responses can reduce the number of requests your application needs to make to process transactions.
Error Handling
If your application exceeds rate limits, make sure you have error handling in place to catch the 429 HTTP Error and handle it appropriately. Error handling can include retrying the request later or displaying an error message to the user.
Webhooks
Instead of using GET requests to retrieve data, setup webhooks to be programmatically alerted of responses and changes to resources you manage.