resend threw 429s halfway through a 2,400 person waitlist blast Waitlist

Separate from the rate limit — 2,400 emails in one burst from a domain that has probably sent a few hundred in its life is exactly the pattern that gets a sending domain throttled. Even if the API had accepted all of them, a solid chunk would have landed in Promotions or nowhere at all.

Spread it. 300 an hour across the day. Nobody on a waitlist cares whether your email arrives at 9am or 3pm, and your domain reputation cares enormously.

Promise.all over 2,400 sends is 2,400 concurrent requests, so you did not hit the limit halfway, you hit it immediately and 600 happened to squeak through before the bucket emptied. The default is around 2 requests a second on most plans.

Two changes. Use the batch endpoint instead of one call per recipient — it takes up to 100 messages per request, so 2,400 people is 24 calls, not 2,400. And write the send state before you send, not after:

UPDATE subscribers SET state='claimed', batch_id=$1
WHERE id = ANY($2) AND state='pending'
RETURNING id

Only send the rows that come back from the RETURNING. Now the process can die anywhere and a re-run picks up exactly what is left, and nobody gets two copies.

Put an await sleep(100) between sends and you are at 10 a second, comfortably under any provider limit. Sequential loop, no concurrency library, done in four minutes.

For tonight: query everyone with no successful send row, chunk it, send those. Then for the next launch stop hand-rolling it and use a broadcast or audience feature — you get suppression lists and unsubscribe handling for free, and you stop owning the boring half of the problem.

Every launch script I have ever written eventually needed a resume flag. Assume the process dies at 40% and design for it on line one. Same lesson as any batch job, it just hurts more when the batch is people.