Rate Limits
Orbit enforces rate limits to ensure platform stability and fair usage. Limits are applied per API key at the endpoint level, and the same limits apply to every account. If your integration needs more throughput, we can raise a limit with a per-organization override — there is no separate plan tier to upgrade to. See Requesting Higher Limits.Overview
Every API response includes rate limit headers:
When you exceed a rate limit, Orbit returns
429 Too Many Requests with the RATE_LIMITED error code.
Limits by Endpoint
Messaging
These per-channel send limits are the defaults that apply to every account. If your SMS (or any other channel) volume needs more headroom, we can raise the limit for your organization with a per-organization override — see Requesting Higher Limits.
Voice
Agents
Numbers
Contacts & Campaigns
Billing & Webhooks
Handling Rate Limits
Best Practices
- Check headers proactively. Monitor
X-RateLimit-Remainingand slow down before hitting zero. - Implement exponential backoff. When receiving a
429, waitretry_afterseconds, then retry with increasing delays. - Queue and batch. For high-volume sends, queue messages and send in controlled batches.
- Use webhooks instead of polling. Subscribe to status webhooks rather than polling
GET /api/v1/messages/{id}.
Retry Example
Global Per-Second Limit
In addition to the per-minute endpoint limits above, a single global limiter caps every API key at 50 requests per second as a platform safety net. This ceiling is applied uniformly to all callers regardless of plan — it is not a separate per-plan tier and there is no burst queue. Requests beyond 50 req/sec receive429 Too Many Requests immediately; they are not queued or delayed before rejection. In practice the per-minute endpoint limits above are the binding constraint for normal usage, so this global ceiling is rarely the limit you hit first. Apply the same exponential-backoff handling described above when you do.