Rate limits and throttling
Our message sending APIs are built to handle high-volume traffic and sudden spikes. Actual end-to-end throughput can still be constrained by downstream channel providers (for example, telecom networks) that sit between Infobip and the recipient. Check the product's channel documentation for more details.
For non-message sending APIs, requests are throttled if usage exceeds expected levels. If this happens, you'll receive an HTTP status code 429 - Too Many Requests. This usually means that the API endpoint is being used in a way that was not designed to be used. In these situations, we recommend to explore other endpoints which may be more suitable for your use case or to contact us.
Throttling
One of the specific errors that can occur with your requests is a throttling error. It will generally be denoted by an HTTP status code 429 (TOO_MANY_REQUESTS), and it happens when you make too many requests to a specific endpoint within the configured rate limits.
Infobip API uses token-based rate limiting to control request rates. Different endpoints may have different throttling configurations, and you should consult the specific API documentation for each endpoint to understand the applicable limits.
Rate limit types
API endpoints may be protected by one or both of the following rate limit mechanisms:
- Time-based rate limit: Limits the number of requests within a fixed time window. Example: 100 requests per 10 seconds
- Token-based rate limit: Uses a token bucket algorithm that allows bursts while maintaining a steady refill rate. Example: Burst capacity of 5 requests with a refill rate of 1 request per second
Handling throttled requests
In case one of your API requests ends up being throttled, you should implement exponential backoff and retry logic. Wait for a short period before retrying, and increase the wait time with each subsequent throttled response. However, be mindful of retrying too many times, as excessive retries can cause even more requests to be throttled.
When implementing retry logic, make sure to:
- Include a limit on the number of retries
- Implement exponential backoff between retries
- Monitor the overall number of throttled requests
If too many of your requests end up being throttled consistently, you might be using the API in an unsupported way or need to optimize your request patterns.