Posthawk has two independent throttle layers — understanding both prevents surprises:

1. Per-API-key request rate limits (incoming HTTP)

Every API key has three rate limit tiers:

• Hourly: 100 requests
• Daily: 1,000 requests
• Monthly: 10,000 requests

These apply to the /v1/send endpoint. When you exceed a tier, the API returns a 429 with name: "rate_limit_error" and a retryAfter field giving the seconds to wait before retrying. See Errors for the full retry pattern. Check the response headers for current usage:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1719849600

2. AWS SES outbound throughput (worker → SES)

AWS SES enforces a per-account maximum send rate — currently 14 emails per second for the Posthawk Cloud account. Exceeding it triggers ThrottlingException from SES and harms reputation.

To stay safely under that ceiling, the Posthawk worker limits SES dispatch to 12 emails per second across all queue workers, configured via BullMQ limiter: { max: 12, duration: 1000 }.

What this means in practice:

• The API accepts requests as fast as the per-key rate limits allow — there is no 429 from the throughput limit, queued emails just drain at ~12/sec.
• Bursty workloads (a 100-email batch, a broadcast to 1,000 contacts, a scheduled batch firing at 9:00am) queue instantly but drain at ~12 emails/sec through SES. A 1,000-recipient broadcast takes ~83 seconds to fully ship.
• GET /v1/send/:jobId lets you observe drain progress.
• All outbound paths share the queue — API /v1/send, batch /v1/batch, scheduled emails firing, broadcast fan-out, newsletter issue sends, and SMTP relay all consume the same 12/sec budget.

To raise the ceiling, request an SES sending-rate increase from AWS. After approval the worker limit can be raised to match.