Rate limits

Account-level

Endpoint family	Limit	Window
POST /emails	50 req/sec	rolling
POST /emails/batch	10 req/sec	rolling
POST /campaigns/{id}/preview (LLM)	10 req/min	rolling
All other endpoints	200 req/sec	rolling

When a request is rate-limited, you get 429 Too Many Requests with these headers:

X-RateLimit-Limit: 50
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1714000000
Retry-After: 1

X-RateLimit-Reset is a Unix timestamp; Retry-After is seconds.

Per-IP daily caps

Each sending IP carries a daily_limit based on its warmup phase. When all IPs in the targeted pool hit their caps, queued emails wait — they are not rejected. The dispatcher resumes at midnight UTC (or whenever the rolling window opens).

You can increase headroom by:

• Adding more IPs to the pool (POST /pools/ips)
• Promoting IPs to higher warmup phases (happens automatically with healthy metrics)

Best practices

• Add backoff with jitter. When you hit 429, wait the Retry-After plus 100–500ms of jitter.
• Respect X-RateLimit-Remaining. Track it in your client to throttle proactively.
• Use batch when sending many at once. POST /emails/batch is one request slot, up to 100 emails.
• Don’t loop tightly. A for loop sending 10K emails will hit the rate limit. Use a campaign instead.