Rate limiting

To guarantee the stability and availability of the API for all our users, every endpoint of the SMS Partner API applies a rate limit. This limit defines the maximum number of requests you can make to a given endpoint within a given time window.

How it works

The limit is applied per endpoint and per calling IP address. Each endpoint has its own quota, independent of the others: using up your quota on one endpoint does not affect your quota on another.

The quota is automatically reset when the time window associated with the called endpoint expires. There is nothing you need to do on your end to reset it.

The exact limits (number of allowed requests and window duration) vary by endpoint, depending on their nature and their cost to our infrastructure. If you need a higher quota for a specific use case, contact our support team.

Exceeding the limit

When an endpoint's quota is exceeded, the API responds with the HTTP status code 429 Too Many Requests and a JSON response body of the form:

{
  "success": false,
  "code": 429,
  "message": "Too many requests, please slow down.",
  "readableLimit": "30 request per 60 secondes"
}

In this case, no action is performed server-side: the request is simply rejected, with no side effects.

Response headers

On a 429 response, the API also returns the following headers, which let you know the exact state of your quota:

Header	Description
X-RateLimit-Limit	Maximum number of requests allowed within the endpoint's time window
X-RateLimit-Remaining	Number of requests remaining in the current window
X-RateLimit-Timeleft	Number of seconds before the quota resets

Full response example:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 30
X-RateLimit-Remaining: 0
X-RateLimit-Timeleft: 42
Content-Type: application/json

{
  "success": false,
  "code": 429,
  "message": "Too many requests, please slow down.",
  "readableLimit": "30 request per 60 secondes"
}

These headers are only guaranteed on 429 responses. Do not rely on their systematic presence on successful responses to anticipate your remaining quota.

Best practices

• Respect X-RateLimit-Timeleft before retrying your request rather than retrying immediately in a loop.

• Implement backoff (increasing delay between attempts) in case of repeated 429 responses.

• Avoid aggressive polling: prefer webhooks over regularly polling a status endpoint whenever possible.

• Batch your calls whenever the endpoint allows it (e.g. bulk sending rather than several individual calls), in order to limit the number of requests needed.

Need a higher quota?

If the default limits do not fit your usage volume, contact our support team with the endpoint concerned and your requirement: we will look into adjusting your quota.