Rate limits and throttling

Infobip 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). Check the documentation of the channel for details.

Requests are throttled when usage exceeds the rate limits of the endpoint, returning HTTP status code 429 Too Many Requests. Most rate limits apply to non-message-sending APIs, but some send endpoints also have them, for example Email. The API reference page of each endpoint lists its limits.

When a request is throttled, back off and retry, as described in Handling throttled requests. Persistent throttling usually means that the endpoint is being used in a way it was not designed for. Look for an endpoint more suitable for your use case, or contact Support.

Throttling

A throttling error is denoted by HTTP status code 429 (TOO_MANY_REQUESTS). It happens when you send more requests to an endpoint than its rate limit allows. Most endpoints return the error in this format:

Some endpoints return a previous version of the error:

Rate limit types [#rate-limit-types-throttling]

API endpoints can be protected by one or both of the following 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 enables 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 [#handling-throttled-requests-throttling]

If one of your API requests is throttled, implement exponential backoff and retry logic. Wait for a short period before retrying, and increase the wait time with each subsequent throttled response. 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

For a retry example with backoff, see Retry safely. Retrying a send request that timed out or returned a 5xx is a different case. The message might already have been accepted, so a retry can deliver it twice.

Logs endpoints have low limits, for example 120 requests per minute for SMS logs and 60 per minute for Email logs and reports. To track message status, use webhooks instead of polling logs. For all API error codes, see the Error code reference.