Rate limits

Each API key is rate-limited independently. Limits are enforced server-side and exposed 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-Id with 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.