Make Resend sends idempotent: key format, 409 handling, retry discipline

TL;DR: A pipeline pattern for exactly-once email semantics on Resend: derive the idempotency key from the business event, send it in the header, and handle the three duplicate responses correctly. Retries stop being scary. Build an idempotent send pipeline 1. One business event always maps to one key, so a retried worker can never mint a second send.

Build an idempotent send pipeline

1. Derive the idempotency key from the business event, not a random value: format it as [event-type]/[entity-id], for example receipt/ord_789. One business event always maps to one key, so a retried worker can never mint a second send. Docs: https://resend.com/docs/dashboard/emails/idempotency-keys
2. Send the key in the Idempotency-Key HTTP header on POST /emails, or as the Resend-Idempotency-Key mail header over SMTP. SDKs expose it as an option on the send call; keep keys under 256 characters.
3. On success, store the returned email id keyed by your idempotency key. A later retry with the same key returns the original email id without sending again, which is how you confirm the dedupe worked.
4. If you get a 409 invalid_idempotent_request, stop: the same key was used with a different payload. Retrying is useless; change the key or the payload and investigate why the key collided.
5. If you get a 409 concurrent_idempotent_requests, the first request is still in flight. Wait and retry later with the same key; do not mint a new key or you will double-send.
6. For batch sends, key the whole batch, for example team-quota/workspace_123, because the batch endpoint takes one key per request, not one per email.
7. Remember keys live for 24 hours. Idempotency covers retries inside that window; after 24 hours the same key would send again, so your own sent-record is the long-term dedupe store.
8. Test the pipeline by sending twice with the same key in staging and asserting you receive one email and identical responses. If you get two mails, the key is not reaching Resend.

When to use this

• This covers exactly what the title says: Make Resend sends idempotent.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Make; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Make behavior.

Verified against the Resend idempotency-keys docs on 2026-09-26: keys go in the Idempotency-Key header on POST /emails and POST /emails/batch (Resend-Idempotency-Key over SMTP), keys persist 24 hours, 409 invalididempotentrequest means the key was reused with a different payload, and 409 concurrentidempotentrequests means the first request is still in flight.