Default Limits
By default, the gateway enforces the following high-throughput limits:- 100 requests per second
- 1,000 requests per minute
If you have a high-volume enterprise plan, your specific rate limits may be higher. The HTTP headers returned with every request will always reflect your current limits.
Rate Limit Headers
Every API response includes standard HTTP headers that provide real-time information about your current rate limit status. You can use these headers to pace your requests dynamically in your code.| Header | Description |
|---|---|
X-RateLimit-sec-Limit | The maximum number of requests you are allowed to make per second. |
X-RateLimit-sec-Remaining | The number of requests remaining in the current one-second window. |
X-RateLimit-min-Limit | The maximum number of requests you are allowed to make per minute. |
X-RateLimit-min-Remaining | The number of requests remaining in the current one-minute window. |
Handling Rate Limit Errors
If you exceed the allowed number of requests, the API will reject subsequent requests and return an HTTP429 Too Many Requests status code.
The response body will use our unified error format, clearly indicating how long you need to wait before making another request via the retry_after parameter.
Best Practices for High Volume Sending
- Implement Backoff: If your code receives a
429error, parse theretry_afterparameter from theerrors.paramsobject, and pause your application’s request loop for that duration before retrying. - Queue Your Traffic: For massive outbound messaging campaigns, do not use a simple
forloop. Use an internal queue (like RabbitMQ or Redis) to throttle your own traffic so it stays slightly below the maximum allowed limits (e.g., emit at 90 req/sec).