Rate limits
Each API key is rate-limited independently. Limits are enforced server-side and exposed to your application via response headers so you can back off gracefully.
Defaults
| Limit | Default | Configurable per key |
|---|---|---|
| Requests per minute | 60 | Yes |
| Daily SMS | Unlimited | Yes |
| Monthly SMS | Unlimited | Yes |
| Bulk recipients per request | 1,000 | No |
Higher request-rate limits are available on Business and Enterprise plans. Contact support to have them lifted on a specific key.
Response headers
Every successful response carries the current state of the rate limiter:
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 58
X-Request-Id: req_dXp9k...Exceeding a limit
When the per-minute window is exhausted, the API responds with 429 Too Many Requests:
{
"success": false,
"error": {
"type": "rate_limit_error",
"code": "rate_limit_exceeded",
"message": "Rate limit exceeded. Maximum 60 requests per minute."
},
"meta": { "request_id": "req_dXp9k..." }
}
Backoff strategy. When you receive a
429, wait until the next
full minute window before retrying. Avoid retrying with no delay — it will keep the bucket
drained and prolong the outage.
Recommended patterns
- Use a single bulk request rather than many singletons when sending to a list.
- Persist the
X-Request-Idwith your records — it makes support tickets dramatically faster. - Distribute traffic across multiple workers, but use one key per worker for cleaner attribution.
- Switch to webhooks instead of polling for status — you'll save the entire rate-limit budget for actual sends.