Rate limits

Request limits#

• Limits use fixed one-minute windows.
• Access tokens count against the API key they were issued from, so exchanging a key for tokens doesn't add capacity.
• Every API key has its own allowance; so does every person using the console.

Headers#

Every response from a limited endpoint says where you stand:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json; charset=utf-8
X-RateLimit-Limit: 1200
X-RateLimit-Remaining: 0
Retry-After: 60

{"error":{"code":"rate_limited","message":"Too many requests. Slow down and retry shortly."}}

Staying under the limit#

• Fetch lists in pages of up to 500 (limit=500) instead of loading objects one by one.
• Subscribe to webhooks, or read GET /events/stream, instead of polling campaigns for progress.
• Reuse an access token for its whole hour.
• On a 429, wait for Retry-After. Retrying sooner only uses up the next window.

Plan limits#

Plans cap what an organization can have at once. Going over fails with 403 plan_limit_reached and a message naming the limit: connecting another account, adding or importing more recipients, inviting another member or launching another campaign waits until something is removed or the plan changes. Platform administrators change plans; GET /organization/usage shows where you stand.

Active campaigns are those scheduled, running or paused; team members count pending invitations. Every plan includes API access. Each campaign can also reach at most 50,000 sendable recipients, a platform setting.

Telegram pacing is separate#

API limits protect Oqim. Telegram's limits protect Telegram's users, and they apply to each account: its daily limit and minimum interval in Oqim, flood waits that Telegram imposes, and restrictions for accounts that message people who don't expect it.