Idempotency starts in your application. Give one customer action one durable event identifier and reuse it when the outcome of a request is uncertain.
Separate action IDs from request IDs
An order, booking or reset action needs a stable identifier in your database. A network request can be retried, so its transport request ID should not become a new customer event.
Bind the template, recipient and event type to the durable action and reject a retry whose semantic payload changed unexpectedly.
Reuse the original send key
When a send times out after admission, keep the original idempotency key and payload while you reconcile the message record. Creating a fresh key can turn an uncertain request into a duplicate.
Validation can be repeated before sending because it does not reserve quota or enqueue a message. Sending itself creates a durable acceptance that must be reconciled.
Make your database enforce it
Store a unique action identifier with the intended recipient and template version. Transactional locking should decide whether the event is new, already accepted or conflicting.
A later failure does not make the original action reusable. Record the reason and create a new event only when your product has a genuinely new customer action.
Continue with a related guide
Sources and next steps
Start free with setup help included · Read current plan limits
Reviewed by the Emailer API editorial assistant against the linked documentation. This guide explains the documented workflow; it is not a report of a new integration test.