Skip to main content
Brudcast limits how fast each credential and each IP address can call it, and how much mail each organization can send. When you hit a limit you get a 429, and waiting always clears it.

Platform API

Each API key has its own budget, so two keys never share one. Every response tells you where you stand. When a key has both windows, the headers describe whichever is closer to running out. A request over the limit fails with 429 and two extra headers, Retry-After (seconds) and X-RateLimit-Reset (an ISO 8601 time):

Email send API

The send API applies limits per client IP address and per organization. The per-IP limits send RateLimit and RateLimit-Policy headers on every response and Retry-After on a 429.

Organization sending limits

Every organization has sending limits in five windows. All windows run on UTC. So one call to 50 recipients counts once against the second, minute and hour windows, and 50 times against the day and month windows. The numbers depend on your plan and how long your account has been sending. New accounts start lower and grow. See New account sending limits. A few rules make these predictable:
  • A request is accepted whole or not at all. If 50 recipients would take you past the daily limit, the whole request is refused. No recipient is sent.
  • Refused requests cost nothing. A request refused by any window doesn’t use up budget in the others.
  • The message names the window. Rate limit exceeded: perDay means you’re done until midnight UTC. Don’t retry in a loop.
  • The same limits apply to SMTP and campaigns. Campaign messages over a limit are held and retried for up to 24 hours.

SMTP relay

The relay applies your organization’s sending limits once per SMTP transaction, when your client sends MAIL FROM. A transaction counts as one request and one recipient, however many recipients follow. Over a limit, the relay replies 451 Rate limit exceeded: <window>. 451 is a temporary failure, so a standard SMTP client queues the message and retries on its own.

Handling a 429

  1. If the response has a Retry-After header, wait that many seconds.
  2. If it doesn’t, back off exponentially: wait about 1 second, then 2, then 4, up to a minute, with some random jitter.
  3. If the message names perDay or perMonth, stop and resume after the window resets.
The email send API doesn’t deduplicate requests. Retry a send only when you got a response that says it wasn’t accepted, such as a 429 or 5xx. If the connection dropped before any response arrived, the message may already be queued. See Retries and duplicate sends.

Staying under the limits

  • Use one API key per integration, and set each key’s per-minute limit to what it needs.
  • For bulk or marketing mail, send a campaign instead of calling the send API in a loop. Campaigns are paced for you.
  • Watch X-RateLimit-Remaining and slow down before it reaches zero.

API keys

Set a key’s per-minute and per-day limits.

Errors

Every 429 message and what it means.

Email send API

When a send is safe to retry, and how to avoid duplicates.

New account sending limits

Why a new organization’s limits start low and grow.