Rate limits

Two limits apply, and they exist for different reasons.

Limit	Applies to	Default
Per service	authenticated calls, counted per grant	60 requests per minute
Before authentication	all calls from one source address	300 requests per minute

The per-service limit

Counted per grant, which means per service, not per credential and not per short code. Two services under the same credential have separate budgets and do not compete with each other.

Exceeding it returns RATE_LIMITED with a Retry-After header telling you how many seconds until the window reopens. Use the header rather than guessing: it is exact, and backing off by a fixed interval either wastes time or fails again.

The pre-authentication limit

Applies before we know who you are, keyed on your source address. It bounds what an unidentified caller can cost us, including someone probing with an invalid token.

You should never meet it. If you do, you are almost certainly retrying failed authentication in a loop: fix the credential rather than the rate.

Handling RATE_LIMITED properly

It is one of only five retryable codes, so retrying is legitimate, but do it well:

• Honour Retry-After. Sleep for what it says.
• Add jitter if you run several workers, or they will all retry in the same instant and you will limit yourself again.
• Do not retry indefinitely. Persistent limiting is a capacity conversation with the operator team, not a problem to solve with a tighter loop.

If the limit is wrong for your service

The per-service limit is configurable. If your legitimate traffic exceeds it, that is a conversation rather than something to engineer around: batching, parallelising or spreading across credentials will not help, because the budget follows the service.