Rate limits

How many emails you can send, and the other ceilings a request can hit. The per-key limit is not keyed by IP. A separate edge limit is, and it counts requests that present a credential, by source address. The per-key limiter and the daily send counters refuse the request when their store is down. The edge limit and the per-address hourly ceiling let the request through.

Limits

Limit	Scope	Status	limit.dimension	Binds	Resets
Per minute	One API key	429 limit_exceeded	api_rate	The key, when it has its own rate, otherwise the plan. A key cannot be set above the plan.	The end of the current 60-second window. Retry-After is the seconds left in it.
Edge	Source address, and only a request that presents a credential	429 edge_rate_limited	—	600 a minute by default. If this limiter is down, the request is allowed through.	That same 60-second window. Retry-After is the seconds the limiter reports.
Daily send	The account	429 limit_exceeded	daily_send	The lowest of the plan, the account and the application for this send. A member ceiling is a separate counter.	Midnight in the account's timezone. Retry-After is the seconds until then, at least 1.
Application daily	One application	429 limit_exceeded	application_daily_send	That application's own daily limit, when it has one	The same midnight
Member daily	One member	429 limit_exceeded	daily_send	member, when that member has a daily send limit	The same midnight
One address, per hour	One account and one recipient address	429 limit_exceeded	recipient_messages_per_hour	The account. 60 messages by default, or the account's override. If the store is down, the send is allowed through.	The current UTC clock hour: the count starts again at the top of each hour. Retry-After is 600 seconds, which can fall inside that hour.
Recipients in one message	One send, across to, cc and bcc	422 limit_exceeded	recipients_per_message	The platform. 100 recipients by default.	No clock, and no Retry-After
Content views	One person, or one shared bucket for keys with no user	429 content_view_quota_exceeded	—	A plan cap, an operator override of it, or a member override. No plan ships with one set. A member override applies on its own when the plan has none, and it cannot raise a plan cap.	Midnight in the account's timezone. This 429 sends no Retry-After.
Monthly allowance	The account	Not a refusal. The send is still 202, with over_monthly_quota true	—	The plan's messages per month. It counts accepted calls, not recipients.	The account's calendar month

When the per-key limiter or a daily counter cannot reach its store, the request is refused with 503 dependency_unavailable and Retry-After: 30. GET /v1/usage names the zone as period.timezone and the day as period.day. That zone's midnight is when the daily counters, the content-view day and the monthly key roll. daily.limit on that response is the plan and account ceiling only, so it can be higher than the cap a particular application or member hits.

Per-minute bucket

Your plan sets it: Free 60 · Pro 300 · Scale 600 · Team 1200 · Enterprise 3000 requests per minute. A key may be minted lower at mint, never higher than the plan. Exceeded → 429 with type: limit_exceeded and dimension: api_rate. If the limiter's store is down the request is refused with 503 and Retry-After: 30.

response body

HTTP/1.1 429 · Retry-After: 42
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0

{
  "message": "API rate limit exceeded: used 60 of 60 requests this minute. Wait for the next minute window, or raise the key/plan API rate limit.",
  "type": "limit_exceeded",
  "limit": {
    "dimension": "api_rate",
    "binding": "plan",
    "limit": 60,
    "used": 60,
    "lift": "Wait for the next minute window, or raise the key/plan API rate limit."
  }
}

Daily send limit

The account counter is the lowest of the plan, the account and the application, and it counts recipients on accepted sends. A member limit counts that member's own sends. An application with its own daily limit is checked again on its own counter. All three reset at midnight in the account's timezone, and Retry-After on these 429s is the whole number of seconds until that midnight, at least 1. The 21600 in the sample is six hours before midnight, not a fixed delay. Monthly quota is a signal only — overage sets over_monthly_quota: true on the 202 and does not block the send.

response body

HTTP/1.1 429 · Retry-After: 21600

{
  "message": "Daily send limit exceeded: plan daily send limit — used 1,000 of 1,000 recipients today. Upgrade your plan to raise the daily send cap, or wait until midnight (UTC).",
  "type": "limit_exceeded",
  "limit": {
    "dimension": "daily_send",
    "binding": "plan",
    "lift": "Upgrade your plan to raise the daily send cap, or wait until midnight (UTC).",
    "limit": 1000,
    "used": 1000
  }
}

Response headers

A response that has passed the per-key limiter includes X-RateLimit-Limit and X-RateLimit-Remaining. Those two numbers are the minute bucket, including on a later daily-cap 429. They are not on the edge 429, which is refused before that limiter runs. On a 429, honour Retry-After and reuse the same Idempotency-Key. For the minute bucket it is the seconds left in the 60-second window. For daily_send and application_daily_send it is the seconds until midnight in the account's timezone, the same boundary period.timezone and period.day name on GET /v1/usage, and it is at least 1. The per-address hourly ceiling sends Retry-After: 600. A content-view 429 sends no Retry-After.