Shipping notification emails: triggers, timing, 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.

Verifying the carrier webhook is real

A shipping notification triggered by a spoofed webhook is a low-severity but real annoyance vector, a customer getting a fake "delivered" email for an order that hasn't shipped erodes trust fast. Most carrier and fulfillment platforms sign their webhooks (a header-based HMAC signature, similar in principle to how Envello signs its own delivery webhooks); verify that signature before treating the payload as trustworthy, the same discipline covered in the webhook signature verification post.

Multi-package orders

An order that ships in multiple packages from different warehouses generates multiple carrier events for what the customer experiences as one order. Decide up front whether to send one notification per package (more noise, but accurate per-item tracking) or batch them into a single "your order has started shipping" email with per-item status, since sending five separate "shipped" emails for a five-item order that ships in five boxes reads as spam even though each individual email is technically correct.

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.

Testing without a live carrier integration

Most carrier APIs (Shippo, EasyPost, or a direct carrier integration) offer sandbox modes that fire realistic test webhooks without a real package moving. Combine that with Envello's test-mode API keys, and the whole pipeline, from a simulated carrier event through to a rendered, would-be-sent notification, is testable end to end before a single real order ships.