Track and trace looks like a solved problem from the outside. Shipments have statuses, carriers expose those statuses, and a platform displays them. The difficulty is that there is no shared definition of what a status means, no consistency in how carriers deliver it, and no guarantee that the sequence arrives in order or at all. The cost of an integration is dominated by reconciling those differences rather than by connecting to anything. This is routine logistics platform work.
01The vocabulary problem is the whole problem
Each carrier publishes its own status codes, and they do not map cleanly onto one another. One carrier's out for delivery begins when the parcel leaves the depot, another's when the driver scans it onto the vehicle, and a third has no equivalent state at all. Delivered can mean handed to the recipient, left in a safe place, or signed for by a neighbour.
Building a canonical internal status model and mapping each carrier onto it is the single largest piece of work, and it cannot be automated away. It also cannot be done once: carriers add and retire codes, and a code you have never seen will arrive in production and fall through whatever default you wrote.
| Work item | Relative effort | Why |
|---|---|---|
| Canonical status model | High | No industry standard to adopt |
| Per-carrier mapping | High and recurring | Each carrier differs and changes |
| Transport and auth | Low | Mostly conventional APIs |
| Out-of-order handling | Medium | Events do not arrive in sequence |
| Reconciliation and gaps | Medium | Missing events are normal, not exceptional |
02Events arrive late, out of order and more than once
Carrier event streams are not ordered. A scan recorded at a depot may reach you after a later scan from the next facility, because the two systems synchronise on different schedules. Events are also frequently redelivered, and occasionally revised after the fact.
The consequence is that you cannot treat the latest message received as the current state. Store events with their carrier timestamp, derive the current status from the event set rather than from arrival order, and make ingestion idempotent so a redelivered event does not duplicate history or re-trigger a customer notification.
03Absence of events is the normal case
A parcel that is moving normally may produce no scan for two days. Nothing is wrong, it is simply in transit between facilities that scan at handover rather than continuously. A system that treats silence as a problem will generate false alarms constantly; one that ignores silence will miss genuinely stuck shipments.
The workable approach is expectation-based: for each carrier and service level, know how long a gap is normal at each stage, and alert when the gap exceeds it. That requires observing real data before the thresholds can be set, which means the first release cannot include accurate exception detection and should not claim to.
- Model expected dwell time per carrier, service and stage rather than using one global timeout.
- Derive thresholds from observed history, then review them as carrier performance shifts.
- Distinguish no news from bad news in the customer-facing copy.
- Escalate on exceeded expectation, not on elapsed time since the last event.
- Track carrier data quality as a metric; it varies enormously and informs commercial reviews.
04Polling, webhooks and the cost of each
Carriers differ in how they deliver data. Some push webhooks, some expose an API you poll, and a surprising number still exchange files on a schedule. Most multi-carrier platforms end up supporting all three, which means the ingestion layer needs a common internal shape that each transport feeds.
Polling has a direct cost, because rate limits force a choice between freshness and coverage. Polling every shipment frequently is usually not permitted; polling by expected-next-event window keeps within limits while keeping active shipments current, and it is meaningfully more work to build than a fixed interval.
| Mechanism | Freshness | Main difficulty |
|---|---|---|
| Webhooks | Best | Delivery is not guaranteed, needs reconciliation |
| API polling | Good, rate limited | Budgeting calls across active shipments |
| Scheduled files | Poor | Batch windows and malformed rows |
| Portal only | Manual | Avoid; negotiate an alternative commercially |
05Reconcile, because webhooks are lossy
Webhook delivery fails. The carrier retries a few times and gives up, your endpoint was briefly unavailable, or a message was dropped somewhere in between. A system that relies solely on pushed events will accumulate shipments whose state is quietly wrong.
Run a reconciliation sweep that polls the authoritative state for active shipments on a schedule and repairs divergence. This is not redundant engineering, it is the mechanism that makes the pushed path safe to depend on, and it is consistently the item cut from scope that teams add back after the first bad week.
06What to ask before estimating
The variable that dominates cost is the number of carriers and their individual quality, not the shipment volume. Ten carriers is not ten times one carrier, because each brings its own vocabulary, transport, failure modes and support relationship, and the mapping work does not amortise.
Before accepting an estimate, get the carrier list, the documentation for each, and a sample of real event data from every one. Carriers whose documentation does not match their actual payloads are common, and that gap is discovered during integration rather than during estimation unless somebody looks at real data first.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.