Resend 429 rate_limit_exceeded: stay under 10 requests per second per team

Symptom: API calls return 429 with error type ratelimitexceeded ("Too many requests").

1. Confirm the cause: check the response headers on your requests. Resend sends ratelimit-limit (max requests in the window), ratelimit-remaining (left in the current window), ratelimit-reset (seconds until reset), and retry-after (seconds to wait). The default is 10 requests per second per team, summed across every API key on the team, so one noisy service can starve the rest.
2. Note the scope: this is per-second API request rate, not email volume. Bursty loops and parallel workers are the usual cause, not a big send list.
3. Fix: introduce a queue mechanism or reduce concurrent requests per second so sustained traffic stays under the limit. Honor the retry-after header on 429 instead of hammering.
4. If your workload legitimately needs more, contact support to request a rate increase. You can view your team's current limit on the Settings Usage page.
5. Verify: watch ratelimit-remaining on responses during a normal run and confirm it stays positive. You can find all 429 responses by filtering for 429 on the Resend Logs page.

Documented in Resend docs: default limit is 10 requests per second per team across all API keys, raised on request; headers ratelimit-limit, ratelimit-remaining, ratelimit-reset, retry-after follow the IETF draft; 429s found by filtering the Logs page; fix is a queue or fewer concurrent requests. Evidence: resend.com/docs/api-reference/rate-limit and resend.com/docs/api-reference/errors.