Skip to content
Frontmail Docs

Rate limits

Frontmail limits how fast requests can be sent, to protect your credits from abuse and your providers from bursts. Limits are counted in fixed time windows (one second for the plan and key limits, a window you choose for the per-IP limit).

Per organization (plan)

Section titled “Per organization (plan)”

All requests of an organization together – public and private key – share a limit based on the plan:

PlanRequests per second (per organization and per key)Test sends / day
Free220
Starter520
Pro2020
Business 50k5020
Business 100k5020
Business 200k5020

A batch request counts as one request for the rate limit, but each message in it uses a credit – use /v1/send-batch for bulk sending from servers.

Per IP address

Section titled “Per IP address”

Public-key requests are also limited per client IP, so a single visitor or bot can’t use up your organization’s limit. The default is 10 requests per 60 seconds per IP. Owners and admins change it in Security → Rate limit per IP with two fields, Requests and Per (seconds) – the page sums it up as At most N requests per M seconds from one IP address. Private-key requests are not limited per IP. IPv6 clients are counted per /64 network (the block a single home or server connection usually gets), so rotating addresses inside it doesn’t help a bot. The client address is taken from Frontmail’s CDN; requests that try to bypass it are refused.

Per key

Section titled “Per key”

Requests are also counted per key, with the same per-second limit as your plan.

For public-key requests, the plan and key limits (and anomaly detection) only count requests that passed the template lookup and – when the template requires it – the CAPTCHA check. A flood of invalid requests (unknown template_id, missing Turnstile token) is rejected without using up the limit your real visitors need; only a generous flood guard (at least 50 requests per second per organization) applies to such requests. Give each server or job its own private key: if one of them misbehaves, you can see it in Security → Private keys (Last used) and revoke just that key.

When you hit a limit

Section titled “When you hit a limit”

The API responds with 429 rate_limited and a Retry-After header in seconds. The SDKs wait and retry automatically when Retry-After is at most 60 seconds. Rate-limited requests don’t use credits.

HTTP/1.1 429 Too Many Requests
Retry-After: 2


{ "error": { "code": "rate_limited", "message": "Too many requests.", "docs_url": "https://docs.frontmail.dev/reference/errors/#rate-limited" } }

Your email provider has its own limits too (for example, Amazon SES in sandbox mode allows 1 message per second). The sender respects them by pacing delivery – this delays messages but doesn’t reject your requests.

Other protections

Section titled “Other protections”
  • Anomaly detection slows down sudden, unusual spikes of public-key requests to one request every two seconds.
  • Presigned uploads with the public key (POST /v1/uploads) have a daily byte budget per organization (200 × your plan’s attachment limit).
  • The SDK limitRate option throttles a single browser (see Bot protection).
  • The edge (CloudFront + AWS WAF) blocks floods before they reach the API.
  • The dashboard has its own per-user limits, e.g. 10 test sends per minute on top of the plan’s daily test-send limit shown in the table above.