## 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.