Shipping notification emails: triggers, timing, and what breaks

Shipping notifications are usually triggered by a webhook from a carrier or fulfillment system, not directly by user action, which introduces a specific integration failure mode most transactional emails don't have to deal with: the trigger event itself can be delayed, duplicated, or arrive out of order.

The typical trigger points

• Order shipped: usually the most time-sensitive, customers actively expect this the moment tracking becomes available
• Out for delivery: high engagement, but easy to skip if your carrier integration doesn't expose this granularity
• Delivered: closes the loop, and a natural point to ask for a review or follow up on the purchase

The duplicate and out-of-order problem

Carrier webhooks are notorious for redelivery: the same "shipped" event firing twice, or a "delivered" event arriving before an intermediate status update due to processing delays on the carrier's side. Use an idempotency key tied to the actual event (order ID plus status, not just order ID) so a duplicated webhook doesn't send the same notification twice, and check event timestamps rather than assuming webhooks arrive in the order the underlying events actually happened.

What to actually put in the email

A tracking link that goes directly to the carrier's tracking page (not a redirect through your own site that adds a step), the estimated delivery date if your carrier integration provides one, and enough order context (what was ordered, order number) that the email is useful without requiring the customer to log in and look it up.