Rate limits · Email

Email endpoints use the shared rate-limit model — org-level limits, group-based buckets, IETF RateLimit headers, and 429 + Retry-After on exhaustion. This page covers the email-specific groups and numbers. All windows are 1 minute and fixed; only the rate varies by tier or override.

Sending has two dedicated groups, so send quota is never consumed by management traffic (or vice versa):

The limits count requests, not recipients — which makes batching the lever for volume. At base limits, single sends top out at 10 messages per minute, while 5 batch calls can queue up to 500 messages in the same window. If you are sending to many recipients, move to the batch endpoint before reaching for a higher tier — see Sending in bulk.

Most non-send operations — listing messages, reading delivery status, managing domains, webhooks, and suppressions — use the generic management groups shared across the API:

list and read rise with your subscription tier — see Tiers raise your limits below. write stays at its base rate for every tier.

The RateLimit header on each response names the group that matched, so a 429 always tells you which of these buckets you exhausted:

RateLimit: "email_send";r=0;t=35

Your subscription tier raises the send, batch, and read-heavy management limits:

write keeps its base rate (60/min) at every tier — domain, webhook, and suppression management doesn't scale with send volume. Custom-tier ceilings are set by arrangement, and if your throughput outgrows even those, per-organization overrides can raise any group further — contact support.