Welcome to Xendit’s latest documentation. For legacy content, access the previous documentation here or the previous API reference here.

Rate limits

Prev Next

Rate Limiting

API Rate Limiting is a feature that restricts the number of requests a user or account can make to an API within a specific timeframe. This practice prevents excessive or abusive API usage and ensures equitable access to API resources for all users.

Xendit employs the Sliding Window algorithm for API Rate Limiting. This algorithm divides a specific time period (e.g., an hour or a day) into smaller windows and tracks the requests within each window. For instance, with a rate limit of 50 requests per second (RPS) and a one-minute window size, the algorithm permits up to 3000 requests per minute.

Generally, the API Rate Limit is set to 60 requests per minute (RPM) per endpoint per account in Test mode. In Live mode, the limit increases to 600 RPM per endpoint per account. Note that the Rate Limit may vary per endpoint, as specified in the respective API Reference sections. The following headers are included in API responses to provide Rate Limit details:

Response Header

Example Value

Description

Rate-Limit-Limit

600

Indicates the request quota within the time window

Rate-Limit-Remaining

583

Indicates the remaining request quota in the current window

Rate-Limit-Reset

58.37

Indicates the time remaining in the current window (in seconds)

Additionally, each unique IP address of a calling client has a maximum rate limit of 18,000 requests per minute.

Exceeding the rate limit for an endpoint will result in an HTTP status code of 429 (Too Many Requests) with the error code RATE_LIMIT_EXCEEDED. It is crucial to handle this error by throttling requests until the rate limit quota replenishes.

Best Practices for Handling API Rate Limits

  1. Implement rate limiting in your application: As a client, it is essential to implement rate limiting within your application to avoid exceeding the API's rate limits. This can be achieved by tracking the number and timing of requests and comparing them against the API's rate limit policies.  

  2. Handle rate limit errors: Upon receiving an HTTP status code of 429 (Too Many Requests) with the error code RATE\_LIMIT\_EXCEEDED, handle the error gracefully within your application. One approach is to retry the request after a delay, allowing the rate limit quota to replenish.  

  3. Use exponential backoff: When retrying requests after a rate limit error, consider using exponential backoff. This involves increasing the wait time between retries exponentially (e.g., by a factor of two) with each rate limit error occurrence. This strategy reduces the risk of overwhelming the API with excessive retries within a short period.  

  4. Use caching: Caching API request results can decrease the number of API calls and improve your application's performance. By storing and reusing API request results locally until they become stale, you can minimize the need for frequent API requests.  

By adhering to these best practices, you can ensure your application handles rate limits effectively, providing a reliable and consistent user experience.

Xendit may adjust rate limits to prevent abuse or accommodate high-traffic applications. To request a rate limit increase for your account, please contact us at least 4 weeks in advance via email at help@xendit.co. We will review your request and may approve an increase based on your application's needs.