PulsePigeonemail infrastructure

A network timeout is ambiguous to the client: it can't tell whether the request failed before or after the server processed it. Retrying blindly risks sending the same email twice. An idempotency key, attached to the original request, lets a retry with the same key return the original result instead of triggering a second send.

Idempotency keys should be generated per logical send (an order confirmation, a password reset), not per HTTP attempt, so that retries from any layer of the calling stack collapse to the same key rather than each attempt minting a new one.

Keys are scoped and expire after a fixed retention window; reusing an expired key for a genuinely new message will be rejected as a duplicate of the original rather than treated as new.

Where this applies

Related documentation

Further reading

From the blog

Related terms

Webhook

An HTTP callback the sending platform makes to a customer's endpoint to report a delivery event as it happens.

Delivery event

A discrete, timestamped record of something that happened to a specific email after it was sent: accepted, delivered, bounced, opened, and so on.

Transactional email

Email triggered by a specific user action or system event, such as a password reset, receipt, or shipping notification.