Shipment tracking integration: is the whole order delivered?
One pallet has arrived. Another is still in transit. Build a shipment tracking integration that keeps partial deliveries visible to your team and customers.
Areza Digital
A customer orders two pallets. One arrives on Monday; the other is still travelling. Your sales system receives a delivery update and marks the whole order complete. The customer gets a cheerful confirmation, then calls to ask where the missing pallet is.
A shipment tracking integration should be able to answer a precise question: which part of this order does this update describe? Connecting a carrier feed to a green status badge is only useful when that relationship is correct.
For split deliveries, start with the expected contents of the order and the units actually dispatched. Then decide what the customer should see when only some of them arrive.
Keep the order, shipment and physical units connected
An order is what the customer bought. A shipment is a transport movement or grouping recorded by your operation and carrier. A pallet or parcel is a physical unit you may need to track separately. Agree what each term means in your own systems before mapping their statuses.
Keep a record of:
- The order and its outstanding product quantities.
- Each shipment linked to that order.
- The pallets or parcels assigned to each shipment, with their individual references where available.
- Which order lines and quantities those physical units contain.
This last connection matters. Two delivered pallets do not establish that the complete order arrived if a third pallet was never dispatched. Nor does a pallet delivery event establish that its contents were checked and accepted without a shortage.
GS1 uses the Serial Shipping Container Code, or SSCC, to identify individual logistics units such as cartons and pallet loads. It provides a standard reference for tracking a physical unit through the supply chain. Source: GS1 on SSCC identification.
Where your operation already uses SSCCs, preserve them alongside the carrier references. Do not assume that a carrier tracking number and a warehouse pallet identifier are interchangeable.
Check how much detail your carrier actually provides
Before designing pallet tracking around an integration, inspect representative records from the services you use. Can you identify each piece, or does the feed describe only the overall shipment? Does a delivery event identify the unit it concerns?
For example, DHL’s Unified Tracking documentation lists both shipment piece counts and piece-level events, but says their availability depends on the service and product. Optional fields can also be absent. Source: DHL Unified Tracking documentation.
Treat missing detail as a limit on what you can conclude. If you only receive a shipment-level status, label it as the carrier’s shipment status. Do not turn it into a claim that every expected pallet or every order line has been received.
For shipments that need individual confirmation, agree an additional check: a warehouse receipt, a review of the delivery record, or a named person confirming the unresolved unit. Build that check into the work queue instead of hiding the uncertainty behind “delivered”.
An illustrative example: two pallets, two outcomes
Imagine a wholesaler sending 60 cartons on two pallets. Pallet A holds 40 cartons; pallet B holds 20. All ordered quantities have been assigned to these two units.
This is an illustrative example, not an Areza client story or a measured result. Assume the carrier provides a separate reference and delivery event for each pallet.
Swipe or scroll to compare.
| Record | Latest confirmed event | What the team should see |
|---|---|---|
| Pallet A: 40 cartons | Delivered on Monday | Delivery reported for this pallet |
| Pallet B: 20 cartons | Still in transit | Delivery not yet confirmed |
| Order: 60 cartons | One of two pallets delivered | Partially delivered; pallet B remains open |
The customer update could say: “One of your two pallets has been delivered. The second remains in transit. We will update this page when its status changes.” Show a delivery estimate only if you have one, and identify it as an estimate.
When pallet B receives its own delivery confirmation, the order can meet your agreed transport-delivery rule. Any reported damage, missing contents or acceptance requirement should remain a separate visible issue. A transport milestone should not silently resolve it.
Agree the completion rule before sending notifications
For a first implementation, we recommend a conservative rule: mark the order fully delivered only when every required dispatched unit has matching delivery confirmation and no ordered quantity remains unaccounted for.
Keep legitimate changes explicit. If the customer cancels an outstanding line or agrees to a replacement shipment, record that decision and update the expected contents. Do not reduce the expected pallet count just to make the current status look complete.
A useful order summary separates three things: what was expected, what delivery evidence exists, and what still needs attention. A partial delivery status should open a clear next action, such as checking pallet B with the carrier, assigned to a person or team.
Preserve history when updates arrive late
Store the source event and its reference alongside the time it happened and the time your system received it. Use the documented meaning of the carrier’s events to update the current view.
An older in-transit event received after a delivery confirmation should not automatically move the pallet backwards. A repeated delivery event should not count as a second delivered pallet or send the same customer message again. A genuine correction or return needs its own handling; it should not be discarded merely because “delivered” was previously recorded.
Also distinguish stale information from a new delay. If the connection stops updating, show when tracking was last checked and give the team an alert. Silence alone is not evidence that a pallet has arrived or that its delivery date has changed.
Test the awkward cases before rollout
Use a small, representative set of shipments to check these five outcomes:
- Only one unit arrives: the order stays partially delivered and identifies the outstanding unit.
- An order line has not shipped: delivery of the dispatched units does not hide the remaining quantity.
- An update repeats or arrives late: it does not inflate counts, repeat messages or undo a newer confirmed event without a valid correction.
- Piece-level data is unavailable: the page states what the carrier reported and leaves unverified details unresolved.
- The connection fails: the last known event remains visible with its age, and an owner receives the follow-up task.
Start with one carrier service and one dispatch workflow. Check the order summary against dispatch records and delivery evidence before extending the same rules to other services.
Areza’s connected systems work links the records your team relies on. For warehousing and logistics, a useful starting point is tracing one split delivery from the picking list to the customer update. Talk to us about that workflow with an example of where the statuses stop agreeing.