Guides
Shipment Tracking Statuses Explained: From Label Created to Delivered
A practical guide to package tracking statuses, what each status really means, when a shipment is actually delayed, and how to present carrier events to customers.
Tracking pages look authoritative, but a status is only an interpretation of the latest carrier scan. The parcel may be moving while the page is quiet, and a dramatic-sounding event can be routine. Understanding that distinction is the difference between a useful post-purchase experience and a support queue full of avoidable questions.
This guide explains the common shipment states from label creation through delivery, the signals that should trigger action, and the way developers can normalize hundreds of carrier phrases into a small status model without hiding important detail.
Label created or pending
A pending status normally means the merchant created a shipping label and sent electronic shipment data to the carrier. It does not prove that the carrier has the parcel. Phrases such as 'pre-shipment', 'shipment information received', and 'electronic notification' belong in the same family.
The useful customer message is specific: the order is prepared and the next expected event is the carrier's first physical acceptance scan. If the state persists beyond the merchant's stated handling time, the merchant should investigate; before then, repeatedly polling the carrier adds cost without creating new information.
Accepted, picked up, or received by carrier
An acceptance scan is the first strong evidence that custody changed from the sender to the carrier. This is the moment many systems should move an order from fulfilled to in transit. It is also a better trigger for a shipment notification than label creation, because the customer can now expect physical movement.
Some networks skip a visible acceptance event and first show the parcel at an origin sorting centre. A normalized API should infer in_transit from either signal while preserving the original carrier wording in the event timeline.
In transit does not mean continuously moving
In transit covers a long middle phase: origin processing, line-haul transport, hub transfers, flights, customs movement, and destination sorting. A parcel can remain in this state while sitting in a sealed trailer or container for several days. The absence of a scan is not automatically a delay.
Good tracking interfaces show the last confirmed event, its timestamp and location, plus a realistic next milestone. They do not invent a live map position. For international shipments, the next visible event may be customs clearance or a local-carrier handoff rather than another origin-carrier scan.
Customs and clearance
Customs is a process state, not necessarily an exception. 'Presented to customs', 'clearance processing', and 'released from customs' describe different stages. A parcel can pass through with no action from the recipient, or it can wait for duties, an invoice, identity information, or inspection.
Treat customs as its own normalized status when the upstream event is explicit. Escalate it to an exception only when the event requests action or the clearance time exceeds a lane-specific threshold. This avoids alarming customers during ordinary international processing.
Out for delivery
Out for delivery means the parcel was assigned to a final-mile route, not that arrival is guaranteed that day. Capacity, weather, address access, vehicle issues, and route cut-offs can send it back to the depot. The status should create reasonable confidence, not an exact promise unless the carrier supplies a delivery window.
This is a high-value notification point. Show delivery instructions, safe-place guidance, signature requirements, and a direct route to the carrier when available. Avoid sending repeated notifications if the carrier emits several route scans with the same meaning.
Delivered, attempted, and delivery exceptions
Delivered should require an explicit delivery event. A nearby status such as 'arrived at delivery facility' is not enough. Store proof-of-delivery details when available, including timestamp, recipient or location, while avoiding unnecessary exposure of personal data.
A failed attempt, address problem, damage event, refusal, return-to-sender instruction, or held parcel belongs in exception. Exceptions should carry an action: wait for the next attempt, update an address, collect from a depot, pay duties, or contact support. A red badge without guidance creates anxiety rather than clarity.
Build a status model that stays stable
Your product should depend on a small enum such as pending, in_transit, customs, out_for_delivery, delivered, and exception. Map carrier phrases into that model, but keep the raw description and timestamp alongside it. The normalized state drives UI and automation; the raw event preserves evidence.
Trace returns that stable model across more than 80 carriers. One integration can power order pages, notifications, support tools, and analytics without teaching each product surface the vocabulary of every postal and parcel network.
Build tracking into your product
Create a Trace account, generate an API key, and test package tracking from the dashboard.