# Account quotas and limits

> How the daily sending quota, per-request limits, and rate limiting work — and how to get your quota raised.

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).

> **Note:** The exact default value and your current usage are shown in the dashboard. The daily quota is also summarized in [Usage limits](https://www.mailblastr.com/docs/api/limits).

## 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.

> **Note:** Every recipient counts against your quota individually: multiple `to`, `cc`, or `bcc` addresses on one email each count as a separate email toward your daily quota. If you receive email (inbound), each received message also counts as one email against the quota, 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.

```json
{
  "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](https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers). Read these headers to drive **client-side throttling** so you stay just under the limit instead of discovering it via `429`s:

| 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](https://www.mailblastr.com/docs/api/emails-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](https://www.mailblastr.com/docs/webhooks/events) 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?](https://www.mailblastr.com/docs/kb/production-approval).

> **Note:** For the full table of recipient, batch, and attachment limits plus the daily quota, see [Usage limits](https://www.mailblastr.com/docs/api/limits).