Sending limits

Your monthly allowance

Each plan includes a number of messages per calendar month, counted in UTC. It counts accepted messages only: a send we refuse was never attempted, so it is never billed and never counted.

Exceeding it returns 429 with "type": "monthly_limit_reached" and a Retry-After pointing at the start of next month rather than at midnight. Moving to a larger plan lifts the ceiling immediately — there is nothing to wait for.

What else your plan caps

Volume is the limit most people meet, and it is not the only one. Everything the account can hold is capped too — templates, message streams, inbound addresses, seats, sub-accounts — along with how far back delivery analytics may look. Each is refused with 403 and its own error.type, carrying limit and used so a client can show “8 of 10” without parsing a sentence.

Enterprise figures are a floor. A negotiated agreement is stored per account and can raise any of them; it can never lower one below the published tier.

Your account’s daily cap

A new sending account has no history, and volume that appears out of nothing looks exactly like a compromised host to a receiving provider. So capacity is earned rather than granted. Every account starts at 50 messages a day and climbs one rung at a time, roughly doubling, over 10 rungs to a ceiling of 100,000 a day. Roughly doubling is the shape receivers are used to seeing from a business growing into its volume; a jump is the shape they filter.

How the cap moves

The review runs once a day, on your first send after midnight UTC, and looks only at the day before. It moves the cap by at most one rung in either direction.

• Up a rung after a day where you used at least 80% of your current cap, with a complaint rate at or under 0.1% and a bounce rate at or under 5%.
• Down a rung after a day where complaints passed 0.3% or bounces passed 10%.
• Held otherwise — including every idle day. Capacity is earned with real volume, not with time, or an account sending five messages a day would reach the top of the ladder in a fortnight with no reputation at all.

The review is hung off the send path rather than a scheduler on purpose. A cap that only moves when a cron job happens to be alive is a cap that silently stops adapting the first time that job dies.

The platform’s own daily ceiling

The ladder above is per account, and it cannot see the number a receiver actually forms an opinion about. Everyone’s mail leaves from one IP and one sending domain, so what Gmail and Microsoft judge is the total — not any one tenant’s share of it. Ten new accounts each entitled to a full first rung is ten times the first-day volume the warmup schedule promises, from an address with no history to spend.

So there is a second ceiling underneath yours: a cap on what the platform as a whole accepts in a UTC day, checked on every send after your own two limits. When it is reached, sends are refused with 429 and "type": "platform_paused" until the day rolls over or we raise the number.

The number is raised deliberately, by us, as the IP earns reputation — not automatically on a timer. It is conservative on purpose: it is the one limit protecting the asset every account on the platform depends on.

What a 429 looks like

# 429
{
  "error": {
    "type": "daily_limit_reached",
    "message": "This account has sent its daily limit of 1000 messages. …",
    "limit": 1000,
    "sentToday": 1000
  }
}
# retry-after: 32219   (seconds until midnight UTC)

# 429
{
  "error": {
    "type": "monthly_limit_reached",
    "message": "This account has used its monthly allowance of 750 messages …",
    "limit": 750,
    "sentThisMonth": 750
  }
}
# retry-after: 1039821   (seconds until the 1st, UTC)

# 429 — ours, not yours. Carries no account numbers, because none of them
# are the reason.
{
  "error": {
    "type": "platform_paused",
    "message": "We are holding sending briefly while this platform warms up …"
  }
}
# retry-after: 300   (a few minutes, not a calendar boundary)

Nothing over a cap is queued and delivered later. A refused message was never accepted, so it does not appear in your usage figures and is not billed.

A fourth kind of 429 exists and is unrelated to volume entirely: the request rate limit, type rate_limited. Branch on error.type, never on the status code alone — the four need four different responses.

Checking before you hit it

You do not have to wait for a 429 to find out where you stand. GET /v1/me returns sending.dailyLimit, sending.sentToday, sending.remainingToday, sending.warmupTier, sending.sentThisMonth and sending.remainingThisMonth.

GET /v1/usage returns the current period’s totals with the daily series behind them, so you can see which days produced a number rather than taking it on trust. Those counters are derived from the delivery record itself, not tallied separately, which is why they cannot drift from what actually happened.

The shared sending IP

Everything above is per account. Underneath it, the IP your mail leaves from is shared, and it is young — inbox placement is still being established. That is why the ladder is deliberately conservative and why bulk marketing mail is refused outright: on shared infrastructure one bad list damages placement for everybody on it. A broadcast to your own users is sent one message per recipient, and every one of those messages spends the same daily cap and monthly allowance as a single send.

See deliverability for what we can and cannot promise about placement.