Rate Limits
We aim to make our API as fast and accessible for our users as possible.
It is important to keep in mind, our API should be used for the processing of payments only.
Data relating to transactions, customers, and payments should be maintained in your own database. Payments should be sent to us for processing and obtaining the outcome. You should not rely on our API as the primary source of your applications data.
We return rate limit values in the header of every response. The parameters used are:
X-Rate-Limit-Limit integer |
---|
The number of requests allowed in the current period. |
X-Rate-Limit-Remaining integer |
The number of requests remaining in the current period. |
X-Rate-Limit-Reset integer |
The number of seconds left in the current period. |
If one of the above limits is reached you will recieve a response code with a message similar to the one below. We suggest you retry the request after allowing enough time for the limit to reset.
STATUS 429 // Error
{
"message": "Request limit exceeded"
}
Best Practice
When running batch processing of information, we recommend you schedule the batch to be processed between 4am - 4pm AEDST. Do not schedule batches for Sunday.
Where possible, avoid scheduling batch processing of information between 8pm and 3am AEDST to avoid problems occurring due to time-zone differences, inter-bank processing, or interruption from service updates and upgrades.
To get the best performance from the API it is always advisable to;
- Use filters to narrow down search results
- Ensure you implement code to handle paging
- Ensure proper error handling is in place and don't assume requests will always be successful
- Explicitly state which fields you want returned when selecting records
- Always create debit instructions in batches (up to 1,000 per request)
- Use the appropriate endpoints to monitor, acknowledge, and manage failures in batch debits
Comments
0 comments
Article is closed for comments.