How to design multi-carrier shipment visibility

The decision in this scenario

Imagine a logistics team receiving status updates from several carriers through APIs, webhooks and files. A single dashboard is appealing, but 'in transit' can mean different things in each feed, and a missing update can be mistaken for a stationary shipment. This is a representative design scenario, not a client implementation.

A defensible starting approach

We would preserve every source event with its carrier, identifier, event time and receipt time, then map it into a common vocabulary. GS1's EPCIS standard defines a framework for sharing event data about the what, where, when and why of movement. It offers a useful reference model, but it does not mean every carrier feed is EPCIS-compliant or that statuses map one-to-one.

Evidence: GS1: EPCIS and CBV Linked Data Model

Keep raw events before inventing one status

An event such as 'departed facility' may arrive after a later 'delivered' event because networks and integrations are imperfect. Store the original event and the normalized interpretation separately. Reconciliation rules should account for event time, receipt time and source authority instead of simply accepting the latest message received.

Define which questions the shared model must answer: where was the shipment last observed, how fresh is that observation and what exception needs human attention? A single green status without provenance may be simpler to draw but less useful to an operator.

Evidence: GS1: EPCIS and CBV Linked Data Model

Let one carrier fail narrowly

Give each adapter its own error handling, retry policy and freshness signal. Use webhooks where the carrier supports them, but reconcile by polling or file checks if an update can be missed. A feed outage should reduce confidence in that carrier's lane, not erase tracking for every shipment.

The tradeoff is operational complexity: adapters, mappings and exception queues need owners. Before promising real-time visibility, measure each carrier's actual update cadence and display the last confirmed observation to users. 'Live' should describe a measured behavior, not a marketing label.

What the team would need to build and prove

• Per-carrier adapters with isolated failures and source identifiers
• Immutable raw events plus an explicit normalized interpretation
• Event-time and receipt-time handling with reconciliation
• Freshness and exception signals for operators
• A customer view that distinguishes last known from confirmed current state

What success would mean

Success would mean operators can trace every displayed status to a source event, identify stale feeds and resolve exceptions without losing the original evidence. No throughput or delivery improvement is claimed.