Account quotas and limits
How the plan sending quotas, per-request limits, and rate limiting work — and how to raise your limits.
MailBlastr applies two kinds of limit to keep deliverability healthy and protect your sending reputation: sending quotas derived from your plan that cap how many emails an account can send in rolling windows, 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 rejected if it would push you over a sending quota.
Sending quotas
Sending quotas come from your plan, and are measured over rolling windows — not calendar periods that reset at midnight. Both sent and received emails count toward them. As older emails age out of a window, that budget frees up again automatically.
- Free plan — 100 emails per rolling 24 hours and 3,000 emails per rolling 30 days (sent + received combined). The daily cap is an anti-abuse safety rail, not a billing meter — buying email credits does not lift it.
- Paid plans — a monthly volume set by the plan (measured over a rolling 30 days, sent + received combined) with no daily cap.
- When a send would exceed a quota, the request is rejected with a
429—daily_quota_exceededormonthly_quota_exceeded. It is never queued, trickled, or partially sent; retry after the window frees up, or raise the limit (see below).
Per-request limits
Each API call must also stay within these per-request limits:
| Limit | Value |
|---|---|
Recipients per email (to) | up to 50 |
Emails per batch (POST /emails/batch) | up to 100 |
| Total attachments per email | up to 40 MB |
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.
to, cc, or bcc addresses on one email each count as a separate email. If you receive email (inbound), each received message also counts as one email against the quotas, the same as a sent one.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."
}Rate limits are enforced over 60-second windows, per client IP: roughly 30 requests per minute on the send endpoints, 20 per minute on expensive endpoints (such as AI and support), and 120 per minute on general public endpoints. There is no separate burst allowance above the stated limit — once you exhaust the window, the next request receives a 429 until it resets. Because the limit is keyed per IP, requests from multiple services behind the same address 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:
| Header | Meaning |
|---|---|
ratelimit-limit | Maximum requests allowed in the current window. |
ratelimit-remaining | Requests still allowed in the current window. |
ratelimit-reset | Seconds until the window resets. |
retry-after | On a 429, seconds to wait before retrying. |
- 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-remainingapproaches zero.
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.
Raising your limits
Quotas follow your plan, so raising them is self-serve — there is no approval process (see Does MailBlastr require production approval?):
- Upgrade your plan for a larger monthly volume — and no daily cap, since only the Free plan has one. Upgrades take effect on your next send.
- Buy email credits ($0.90 per 1,000) to extend your monthly volume without changing plans. Credits never expire — but they do not lift the Free plan’s daily rail, which only upgrading removes.