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.

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 200 messages a day and climbs one rung at a time:

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.

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 5,000 messages …",
    "limit": 5000,
    "sentThisMonth": 5000
  }
}
# retry-after: 1039821   (seconds until the 1st, UTC)

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 third kind of 429 exists and is unrelated to volume: the request rate limit, type rate_limited. Branch on error.type, never on the status code alone.

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 dedicated IP is available as an add-on if you need your reputation to be entirely your own. See deliverability for what we can and cannot promise about placement.