# Account quotas and limits

> How the plan sending quotas, per-request limits, and rate limiting work — and how to raise your limits.

SendPing 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_exceeded` or `monthly_quota_exceeded`. It is never queued, trickled, or partially sent; retry after the window frees up, or raise the limit (see below).

> **Note:** Your plan limits and current usage are shown in the dashboard. The quotas are also summarized in [Usage limits](https://www.sendping.co/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 quotas individually: multiple `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.

```json
{
  "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](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.sendping.co/docs/api/emails-batch) 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.

## 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 SendPing, 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.sendping.co/docs/webhooks/events) 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 SendPing require production approval?](https://www.sendping.co/docs/kb/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.

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