Ecommerce Delivery Tracking: How to Build Real-Time Order Visibility
How to build delivery tracking: carrier APIs and aggregators, webhooks vs polling, normalizing tracking events, estimates, exception detection and notifications.
Quick answer
Real-time delivery tracking needs a pipeline: record carrier and tracking number when a label is created, receive tracking events from carrier APIs or an aggregator (webhooks where possible, polling as fallback), normalize carrier codes into a small set of statuses, update the shipment and order, recalculate delivery estimates, detect exceptions (including missing scans), and trigger customer notifications and support alerts. Keep raw events for support and analysis, and design everything to handle duplicate and out-of-order events.
From Tracking Number to Visibility
Customers see a tracking page and notifications; behind them is a data pipeline that turns carrier events into reliable statuses. When the pipeline is weak, customers see stale information, get no warning of problems and contact support. This article covers the pipeline. For the customer-facing page and messages, see order tracking.
Pipeline Components
| Component | Role |
|---|---|
| Label creation | Generate label, record carrier, service and tracking number |
| Event source | Carrier APIs or tracking aggregator |
| Ingestion | Webhook endpoint or polling workers |
| Normalization | Map carrier codes to standard statuses |
| Storage | Raw events plus current normalized status per shipment |
| Estimate engine | Carrier estimates or own transit data |
| Exception detection | Explicit exceptions and missing-scan rules |
| Notifications | Customer messages and support alerts |
Carrier APIs and Aggregators
Integrating each carrier directly gives full control but multiplies work: different authentication, formats, rate limits and event codes. Tracking aggregators connect to many carriers through one API and one event format, often with webhooks. Stores with a handful of carriers sometimes integrate directly; stores with many carriers, marketplaces or international shipping usually benefit from an aggregator. Shipping platforms that create labels often provide tracking too. See shipping integration.
Webhooks vs Polling
Webhooks deliver events as they happen, which is efficient and timely. Your endpoint must verify signatures, respond quickly, store events and process them asynchronously, and tolerate duplicates and out-of-order delivery. Polling asks for updates periodically; it's simpler to start but slower and constrained by rate limits. A common pattern uses webhooks as the primary source and polling to catch gaps, such as shipments with no events for longer than expected.
def handle_tracking_webhook(request):
verify_signature(request) # reject if invalid
event = parse(request.body)
if events.exists(event.carrier_event_id): return 200 # duplicate
events.save_raw(event)
queue.enqueue("process_tracking_event", event.id)
return 200 # respond fast; process asyncNormalizing Events
Carriers describe the same thing in many ways. Map their codes to a small internal set of statuses and keep the mapping table maintained as carriers change codes. Store the raw event alongside the normalized status so support can see the original detail. Order events by the carrier's timestamp, not arrival time, and never let an older event overwrite a newer status.
| Normalized status | Example carrier events |
|---|---|
| Label created | Shipment information received |
| In transit | Departed facility, arrived at hub, in transit |
| Out for delivery | With courier, out for delivery |
| Delivered | Delivered, left in safe place, collected |
| Available for pickup | At pickup point, held at depot |
| Exception | Delivery attempted, address issue, damaged, delayed |
| Returned to sender | Return in progress, returned |
Tracking data stale or inconsistent?
ZSpace builds tracking pipelines that normalize carrier events and keep customers and support informed.
Delivery Estimates
Use carrier-provided estimated delivery dates where they exist and are reliable. Otherwise, build estimates from your own history: transit times by carrier, service, origin and destination region, adjusted for weekends and holidays. Update estimates as events arrive, and record the promised date at checkout so you can measure accuracy. See shipping UX.
Exception Detection
Some exceptions arrive as explicit events: failed delivery attempts, address problems, damage, customs holds. Others show up as silence: a parcel with no scan for longer than usual for its route. Set expected intervals by route and flag shipments that exceed them. Route exceptions to customer notifications with clear next steps and to support queues with the context needed to act.
- Explicit exception events mapped and alerted
- Missing-scan rules by carrier and route
- Estimates past due flagged
- Customer message templates per exception type
- Support queue with shipment history attached
- Carrier claim process for lost or damaged parcels
Updating Orders and Notifications
When a shipment's normalized status changes, update the order and emit an event that notification and analytics systems consume. Notifications should be idempotent (one "delivered" message per shipment, even if the event arrives twice) and respect customer channel preferences. See OMS integration.
Split and Multi-Carrier Shipments
One order can have several shipments with different carriers. Track each separately and derive an order-level status (partially shipped, partially delivered). International shipments may hand over between carriers; aggregators often link these, otherwise store the handover tracking number when it appears.
Tracking on Shopify
On Shopify, fulfilments carry tracking numbers and carrier information, the order status page shows tracking, and shipping update notifications can be sent to customers. 3PLs and fulfilment apps typically write tracking back to fulfilments. Tracking apps and aggregators add richer events, branded pages and exception handling. Headless stores read fulfilment data through the APIs and build their own tracking views.
Monitoring the Pipeline
| Signal | Why |
|---|---|
| Webhook failures and latency | Missed or delayed events |
| Shipments with no events after label creation | Handover or integration gaps |
| Unmapped carrier codes | Normalization gaps |
| Estimate accuracy by carrier and route | Promise quality |
| Exception volume by type | Operational problems |
Data for Operations
Tracking events are valuable operational data: on-time rates by carrier and service, regions with frequent delays, time from order to first scan (your own processing speed) and exception rates. Use them in carrier reviews and to adjust promises. See fulfilment technology.
Build, Buy or Aggregate
| Approach | Suits | Trade-offs |
|---|---|---|
| Platform tracking only | Few carriers, basic needs | Limited events and branding |
| Tracking app or aggregator | Many carriers, branded pages | Subscription cost, less control |
| Direct carrier integrations | High volume on a few carriers | Engineering and maintenance |
| Custom pipeline on aggregator data | Custom experiences and analytics | Build effort |
Worked Example
An illustrative scenario, not a client case: a store uses three carriers, each with its own tracking link. Support can't see events without visiting carrier sites. The team connects an aggregator with webhooks, stores raw and normalized events per shipment, adds missing-scan rules by route, shows events in the support tool and triggers delay emails. They monitor unmapped codes and webhook failures.
Common Mistakes
- Older events overwriting newer statuses
- Raw carrier codes shown to customers
- Webhook endpoints doing heavy work synchronously
- No detection of silent shipments
- Duplicate notifications from duplicate events
- No record of promised delivery dates
Ready to build reliable delivery visibility?
Talk to ZSpace about carrier and tracking integrations, Shopify fulfilment data and exception automation.
Conclusion
Delivery tracking is an event pipeline: ingest carrier events reliably, normalize them, keep estimates current, detect exceptions including silence, and drive notifications and support from one shipment record. Related: post-purchase experience and order management systems.
Common questions
When a shipment is created, the store records the carrier and tracking number. Tracking events come from carrier APIs or a tracking aggregator, via webhooks or polling. The system normalizes events into standard statuses, updates the order and triggers notifications.