Account quotas and limits

MailBlastr applies two kinds of limit to keep deliverability healthy and protect your sending reputation: a daily sending quota that caps how many emails an account can send in a rolling window, and per-request limits on how many recipients, batch items, and attachment bytes a single API call may carry.

These limits are independent — a request can be small enough to satisfy every per-request limit and still be held back if it would push you over your daily quota.

Daily sending quota

Every account has a daily sending quota measured over a rolling 24-hour window — not a calendar day that resets at midnight. The quota counts emails actually sent in the last 24 hours, so as older sends age past the 24-hour mark, that budget frees up again automatically.

• New accounts start with a conservative default cap, sized as a safety rail against mailbox-provider limits rather than as a billing meter.
• When a send would exceed the remaining budget, your email is not silently dropped — the request is accepted up to the remaining budget and the rest is queued and trickled out as quota frees up.
• You can request a higher quota as your volume and reputation grow (see below).

Per-request limits

Each API call must also stay within these per-request limits:

Exceeding a per-request limit returns a 422 validation_error describing which limit was hit — split the work across more requests (or use a batch) and retry.

Rate limiting

Send endpoints are also rate limited. If you send too fast you receive a 429 rate_limit_exceeded response. Back off and retry with exponential delay rather than hammering the endpoint — a tight retry loop will keep tripping the limit.

{
  "statusCode": 429,
  "name": "rate_limit_exceeded",
  "message": "Too many requests — back off and retry."
}

The rate limit is enforced as a per-second window with no separate burst allowance above the stated limit — once you exceed the per-second rate, the next request in that same second receives a 429. The limit applies across your whole account: every API key shares the same pool, so requests from multiple services or apps count together toward it.

Rate-limit responses follow the IETF rate-limit header standard. Read these headers to drive client-side throttling so you stay just under the limit instead of discovering it via 429s:

• Batch where you can. A single batch send of up to 100 emails counts as one request against the rate limit, so batching is the most efficient way to push volume.
• Throttle from the headers rather than guessing — slow down as ratelimit-remaining approaches zero.
• Request an increase in advance if you anticipate sustained traffic above your current limit.

Reputation limits: bounce and spam rates

Beyond volume, your account must keep its bounce rate and spam (complaint) rate healthy. These are deliverability guardrails enforced by the upstream mailbox providers as much as by MailBlastr, and breaching them can lead to a temporary pause in sending until the rate recovers.

• Keep your bounce rate under 4%. Remove inactive and invalid addresses, only send to recipients who opted in, and use test addresses (never fake real-looking ones) when testing.
• Keep your spam/complaint rate under 0.08%. Give recipients a clear way to opt out, send relevant and timely mail, and only send with consent.
• Monitor both rates from the dashboard metrics and via bounce and complaint webhooks so you can react before a pause is triggered.

Requesting a higher quota

The daily sending quota is raised on request. Reach out from the dashboard (or contact support) with your expected volume and use case. Higher quotas generally also require production access on the account — see Does MailBlastr require production approval?.