The gap between "shipped" and "delivered" is where support tickets are born: a customer who doesn't know where their parcel is emails you, and someone on your side opens a carrier website to look it up. Almost none of that needs a human. This is how we automate the shipment lifecycle on a live marketplace — registering tracking when a parcel ships, letting carrier webhooks flip the order to delivered, surfacing the exceptions that do need attention, and the unglamorous lesson that saved us the most tickets: test every tracking URL against the carrier's real endpoint before you email it.
The shipment lifecycle you're automating
Every parcel moves through a small state machine: created, shipped, in transit, delivered — with a branch for exceptions like stuck, failed or returned. The goal of automation is that each transition happens because a system observed it, not because a person checked. In a multi-vendor order there isn't one shipment but one per vendor parcel, so the state machine runs per sub-order — the split-order model from multi-vendor checkout — and the customer's view is an aggregate of several parcels moving independently.
Register tracking at ship time
Automation starts at the moment a parcel is marked shipped, whether the vendor does that in their own system or an operator does it in yours. At that instant, capture the tracking number and the carrier, attach them to the correct sub-order, and generate the customer-facing tracking URL. Registering tracking on ship is what makes every later step possible; a parcel with no tracking number is a parcel you can only chase by hand.
Getting the parcel-to-order mapping right matters here: in a multi-vendor order each tracking number belongs to one vendor's parcel, and attaching it to the wrong sub-order sends the customer to someone else's shipment. The per-vendor structure that governs shipping and lockers governs tracking too.
Capture one more thing at ship time: the parcel's delivery target, so the tracking view can tell a locker shopper which machine to collect from and a home-delivery shopper what address the courier holds. The same registration step that stores the tracking number should snapshot enough context that every later notification reads correctly without another lookup.
Let carrier webhooks flip the status
Once a tracking number is registered, you can stop polling and start listening. Most carriers offer status webhooks; subscribe, and map their event codes onto your order states. When a "delivered" event arrives, flip the sub-order to delivered automatically — no dashboard-watching, no manual reconciliation. Where a carrier has no webhook, a scheduled poll is the fallback, but the model is the same: an external event drives an internal state change.
Two operational details save you grief. Make the webhook handler idempotent, because carriers redeliver the same event, and a status flip that runs twice must not send two "delivered" emails. And treat an unrecognised event code as "no state change" rather than an error, because carriers add codes without warning — log the unmapped codes and review them the way you review any other gap.
The mapping is the careful part, because carrier event vocabularies are messy and don't line up one-to-one with your states.
| Carrier signal | Order state | Customer sees |
|---|---|---|
| Label created / pre-transit | Shipped | "On its way" |
| In transit / arrived at depot | In transit | Optional progress |
| Ready for pickup (locker) | In transit | "Ready at your locker" |
| Delivered / picked up | Delivered | "Delivered" |
| Failed / returned / stuck | Exception | Nothing — ops handles it first |
Delivered notifications and exception surfacing
A clean delivered flip can trigger a friendly "your parcel has arrived" note, which closes the loop for the customer. But the higher-value half of tracking automation is the exception path. A parcel stuck for several days, a failed delivery, a return in progress — these should surface to your operations queue before the customer emails to ask. Silence is not the same as success; an automation that only ever reports good news is hiding the cases that actually need a human.
The customer-facing notifications ride the same transactional-email spine as order confirmations and dispatch notices, covered in transactional emails that cut support tickets. Tracking automation is what makes those emails accurate instead of optimistic.
Test tracking URLs against the carrier's real endpoint
Here is the lesson that saved us the most support volume, and it sounds trivial until it bites: a tracking URL you generated but never tested is probably wrong. Carrier tracking URL formats change, vary by service, and are rarely documented well. It is easy to build a plausible-looking URL template that returns a 404 for every real tracking number — and you won't notice, because the link looks fine in the email.
A dispatch email with a dead "track your parcel" link generates precisely the support ticket the whole automation exists to prevent, and it does it at the worst moment — right when the customer is most anxious about their order. So the rule is absolute: for every carrier and service you generate links for, verify the URL format against the carrier's live endpoint using a real tracking number, and re-verify when a carrier changes anything. A tracking link is not done when it is generated; it is done when it resolves.
Orders on our marketplace flip to delivered automatically from carrier tracking webhooks. The habit we had to build was verifying every tracking-URL format against the carrier's live endpoint — we found generated links that looked correct and returned 404s, which is exactly the dead link that manufactures the support ticket you were trying to avoid.
What to show vendors vs customers
The same tracking data serves two audiences that want opposite things. Customers want a calm, plain-language status and one link that works: "on its way", "ready at your locker" (the locker they chose during locker checkout), "delivered". They do not want carrier event codes or depot-scan jargon. Vendors and operators want the raw feed — every scan, every exception, the tracking number, and the controls to intervene on a stuck parcel. Build both views from one event stream, and never leak the operational view to the customer. The customer's trust comes from the status being right and the link being live; everything else is noise to them.
Key takeaways
- Register tracking the moment a parcel ships — the tracking number and carrier on the correct sub-order enable every later automation.
- Let carrier webhooks flip status, mapping messy carrier event codes onto your order states, with polling only as a fallback.
- Surface exceptions before the customer does — a stuck or failed parcel should hit your ops queue, because silence isn't success.
- Test every tracking URL against the carrier's real endpoint; a plausible template that 404s manufactures the exact ticket you were avoiding.
- Serve two views from one event stream: calm plain-language status for customers, the raw feed and controls for vendors and ops.
Frequently asked questions
How does automatic delivered-status tracking work?
Why do tracking links in emails sometimes 404?
What should be automated versus surfaced to a human?
Should customers and vendors see the same tracking view?
From shipped to delivered, tracked automatically.
Our live marketplace registers tracking on dispatch, flips orders to delivered from carrier webhooks, and verifies every tracking link before it reaches a customer.
Request early access See the live marketplace →