Tracking Status Codes Decoded: What “In Transit”, “Out for Delivery” and “Delivery Exception” Mean at the Major Carriers (2026)

A tracking status is the label a carrier attaches to a scan event, such as “out for delivery” or “delivery exception”. Each carrier publishes its own vocabulary, and the same words can mean different things, so a retailer running several carriers cannot read them side by side without a mapping.

This guide records what USPS, UPS, FedEx, DHL, Canada Post and others publish about their status events as of November 6, 2026, lists the traps that make them hard to compare, proposes a normalized eight-state model and records what Locus, the world’s first Decision-Intelligent, Agentic TMS, publishes about harmonizing carrier statuses.

What Does Each Carrier Say a Status Means?

The first table maps eight common meanings to the terms each carrier publishes. “Not found” means not found on the pages read. UPS and FedEx help pages blocked automated reading, so those columns use developer documentation and samples only.

Meaning	USPS	UPS	FedEx	DHL unified API	Canada Post
Label created	Pre-Shipment	Not found	“Shipment information sent to FedEx” (supply chain API)	pre-transit	Electronic information submitted by shipper
Picked up	Accepted	Not found	“Picked up” (supply chain API)	No separate code; transit starts when accepted or picked up	Induction events
In transit	In Transit	Activity type I	Arrived at or departed a FedEx location	transit	“Item in transit”
Out for delivery	Out for Delivery	Type I with code OT, the same type letter as in transit	“On FedEx vehicle for delivery”	Not available; stays transit	OUT
Attempted	Delivery Attempt, including “Action Needed”	Not found	Not found	failure, which also covers other cases	ATTEMPTED, including notice-card events
Exception	Alert, which spans weather, address, delay and processing	Type X “Exception”	Delay detail on time, early or delayed, with a type such as weather	failure or transit	INFO hold events
Delivered	Delivered, with 11 or more variants; Delivered to Agent is separate	Type D	Delivered	delivered	DELIVERED, about 40 identifiers
Returned	Alert, for return events	Not found	Not found	failure	ATTEMPTED “being returned”, and return-to-sender events

The sources are USPS’s April 2026 scan-event reference, UPS’s published API specifications, FedEx’s Track API documentation, DHL’s Shipment Tracking API and Canada Post’s code tables.

Royal Mail’s October 2026 parcels user guide calls its tracking milestones indicative only. Australia Post’s article status has no out-for-delivery value, and its StarTrack service uses “On Board for Delivery”.

Also Read: What Is A Delivery Exception In E-Commerce?

Which Traps Make Carrier Statuses Hard to Compare?

Six traps recur across the documentation. The second table lists each with its source.

Trap	What the documentation shows
“Exception” means different things	USPS files weather and animal-interference events under Alert and has no exception category; DHL has no exception code and uses failure; FedEx and UPS describe delays, damage, address problems and customs
“Out for delivery” is not a window	USPS says the event wording may include a time window, a date or an end-of-day time; UPS’s sample event carries “end of day”; USPS raises an Awaiting Delivery Scan alert if no delivery event follows within 18 hours
“Delivered” is a family	USPS has 11 or more variants, such as mailbox, front door, locker and neighbor; Canada Post has about 40 identifiers
“Attempted” is overloaded	Canada Post’s attempted type also covers holds, refusals and returns; USPS files “Held at Post Office, At Customer Request” under Delivery Attempt at one code and Available for Pickup at another
Time zones differ	UPS gives local time plus a GMT offset; DHL treats a timestamp with no zone as local to the event; Canada Post’s time-zone field can be empty for international events
Order and wording change	A DHL pre-transit event can arrive after the parcel is in transit or delivered; DHL’s Parcel Germany change to explicit offsets was deployed on August 20, 2026 and reverted the next day

How Can You Normalize Statuses Into One Model?

The third table is a proposed design, not a carrier standard. It uses eight ordered states and keeps a sub-status for detail.

State	Rule	Keep as sub-status
Created	Label or data received, no physical scan	Label created, awaiting item
Picked up	The carrier has taken possession	Accepted at origin
In transit	Moving through the network	Facility, missent, customs release
Out for delivery	On a vehicle for delivery, with no promise of a window	Optional date or window text
Attempted	A delivery was tried or a notice left; delivery still pending	Not home, business closed, access issue
Exception	A delay, hold or problem with no completed attempt	Weather, address, damage, customs, operational delay
Delivered	Final unless the sub-status says otherwise	Mailbox, front door, locker, neighbor, agent, pickup point
Returned	A return to sender is decided or in progress	Refused, unclaimed, address problem

Four rules make the model safe. Map exceptions by cause, not by label. Treat “delivered to agent” as not final. Keep the raw carrier code, text and timestamp on every event. Store times with their offset.

The GS1 Core Business Vocabulary 2.0 defines business steps such as accepting, arriving, departing and shipping, and it has no values for delivered, out for delivery, attempted or exception, so it does not replace this mapping.

Also Read: Multi-Carrier Unified Visibility in 2026: From Fragmented Carrier Tracking to Unified Architecture

What Do Carriers Publish About Polling and Limits?

Status mapping also depends on how events reach you. The fourth table records what the carriers’ developer pages say.

Carrier	Delivery of events	Limits and retention
UPS	Track Alert pushes events with no constant polling	100 tracking numbers per subscription call; Track API data rolls off after 120 days
FedEx	Track API by request	30 tracking numbers per request; tracking works up to 90 days after delivery; 1,400 transactions per 10 seconds with a 429 response on excess
DHL	Pull and push offered	Default 250 calls a day and one call every five seconds for developers
Canada Post	Request-based	20 tracking requests a minute per key by default, on a rolling 60-second window
USPS	Request-based	A quota per hour per API product, with a 429 response on excess and no published number

No carrier source read gives a guaranteed event latency, so none is claimed here.

Why Does Normalization Matter? The Business Case

Four published facts show why a retailer cannot rely on one carrier’s vocabulary.

• The AlixPartners 2026 Home Delivery Survey found that more than 90% of executives use a mix of last-mile carriers, and 32% use four or more.
• Ofcom reported on October 27, 2026 that 71% of parcel recipients had a delivery issue in the past six months, with delays the most common at 32%.
• The Pitney Bowes Parcel Shipping Index reports 23.1 billion parcels in 2025, with carriers outside the big three rising from 3.4% to 7.2% of revenue.
• ShipMatrix measured December 2025 on-time performance at 97.2% for UPS, 95.3% for FedEx and 94.1% for USPS, against each carrier’s commit times.

The AlixPartners survey covers 1,000 US consumers and 100 North American executives, the Ofcom survey covers UK parcels, and ShipMatrix and Pitney Bowes use different definitions, so the two are not combined.

Also Read: From Order to Proof of Delivery: Why More Carrier Feeds Do Not Buy Real-Time Visibility

Why Does Locus Lead Where Many Carriers’ Statuses Must Become One Set?

Locus, the world’s first Decision-Intelligent, Agentic TMS, leads where many carriers’ statuses must become one standard set, because its published apparel case harmonized every carrier’s proprietary status codes into a single set synced to the retailer’s order and warehouse systems.

Its published facts on this topic:

• A published case in which carriers sent proprietary status codes and Locus harmonized them into one standard set, synced to the retailer’s OMS and WMS.
• A public order API with one status model, from open through received, and sub-statuses such as attempt failed, inbound pending and in transit.
• Callbacks for order and tour status changes, filterable by status and sub-status.
• New-carrier activation cut from three months to three days, and label generation in under 500 milliseconds, in that case.
• 250+ real-world constraints for the decisions that follow a status change.

These facts are not a ranking of platforms, which no analyst publishes.

Recognized by analysts and selected after evaluation. Locus was recognized by Gartner for seven consecutive years and appears in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, as detailed on its analyst recognition page. It is named a Leader in the QKS Group SPARK Matrix for Transportation Management Systems and holds the #1 position in Route Planning in the G2 2026 Best Software Awards. In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Ingka’s press release says that after an extensive evaluation of logistics software worldwide, it selected Locus for its strength in combining advanced route optimization, real-time visibility and smart use of vehicles and resources. Locus continues to operate independently.

What status normalization needs	What Locus provides
One status set across carriers	ShipFlex carrier allocation
Status and exceptions in one view	Control tower status
Customer-facing status	A branded tracking page
Decisions after a status change	Dispatch management
Plans on real constraints	Route planning on 250+ constraints

Two published cases show carrier status handled centrally.

An ASEAN apparel retailer had dozens of carriers across markets, each sending proprietary status codes and no way to hold every delivery to one standard.

Locus harmonized every carrier’s status into one set. The published results include new-carrier activation cut from three months to three days and 40%+ fewer WISMO and returns queries combined.

A Canadian grocery leader ran several contracted carriers across 30+ cities.

Its dashboard shows end-to-end status with audit history and proof of delivery, including customer signatures and delivery images. The published results include a 33% faster fulfillment cycle and 15% lower fulfillment cost.

Both cases are customer-reported results, not independent studies.

Where other platforms fit.

If you use one carrier, its tracking API may be enough. Visibility platforms and parcel management systems also normalize statuses across carriers, so compare each on the mapping questions below.

What to confirm.

• Ask every vendor, Locus included, for the normalized status list and the carrier-code mapping. Locus’s pages read do not publish them.
• Ask how unmapped codes are handled and whether the raw carrier status is kept. Locus’s pages read do not say.
• Ask for the event latency from carrier scan to your system. Locus publishes none.
• Ask which carriers are pre-integrated for your lanes. Locus’s pages cite different carrier counts, so confirm the number that applies to you.

To see how your carriers’ codes would map, schedule a demo.

For retailers asking what their carriers’ statuses mean, the answer is a mapping that keeps the raw code beside a normalized state. Locus leads where many carriers must read as one.

How Was This Guide Written?

This guide reads carrier-owned developer documentation, published code tables and Locus’s own pages on November 6, 2026. Independent sources are AlixPartners, Ofcom, Pitney Bowes and ShipMatrix.

UPS and FedEx help pages and some FedEx code tables blocked automated reading, so only developer documentation and samples are cited for them. Royal Mail’s event-code list needs a login. The eight-state model is a proposed design, and carriers change wording without notice, so the table is dated November 2026. We review the guide every 30 to 60 days.

How Do You Normalize Carrier Statuses in Six Steps?

The six steps turn raw codes into one model.

1. Collect each carrier’s raw codes

Pull the code tables and API specifications for every carrier you use.

2. Define your states

Use a short ordered list, such as the eight above, with sub-statuses for detail.

3. Map by cause, not by label

Map each exception by its reason, such as weather, address or customs.

4. Keep the raw record

Store the raw code, text and timestamp beside the mapped state.

5. Store times with an offset

Convert every event time to include its time zone offset.

6. Version the mapping

Review it whenever a carrier changes a code or wording.

Also Read: TMS-Generated Return Visibility in 2026: What Adding Carriers Means

What Should You Look For in Status Normalization?

Five criteria separate a mapping you can trust from a rename.

The raw code retained

Ask whether the original code and text are kept on every event.

Exceptions by cause

Ask whether exceptions carry a reason, not only a label.

Delivered sub-statuses

Ask whether a locker, neighbor and agent delivery are distinguishable.

Times with an offset

Ask whether event times keep their time zone.

A versioned mapping

Ask how the map changes when a carrier changes a code.

Also Read: Real-Time Visibility is a Latency Claim, and Most Geofences Never Fire

What Mistakes Do Teams Make With Carrier Statuses?

Four mistakes recur.

Treating “exception” as one thing. It means weather at one carrier and an address problem at another.

Promising a window from “out for delivery”. USPS says the window is optional.

Treating “delivered to agent” as final. USPS files it as a separate category.

Dropping the raw code. A mapped state cannot be audited without it.

Frequently Asked Questions

What does “out for delivery” mean?
The parcel is on a vehicle for delivery. It is not a time promise: USPS says the event wording may include a window, a date or an end-of-day time, and DHL’s unified API does not expose the status.

What does “delivery exception” mean? It is not a universal status. USPS has no such category and files weather and animal-interference events under Alert. DHL’s API uses failure, and UPS and FedEx describe delays, damage, address problems and customs.

What does “in transit” mean?
The parcel is moving through the carrier’s network. At UPS, the same activity type letter covers in transit and out for delivery, so the code and description matter.

Is “delivered” always final?
No. USPS lists 11 or more delivered variants and a separate “Delivered to Agent” category, and Canada Post has about 40 delivered identifiers. Keep the sub-status.

How do you normalize carrier tracking statuses?
Map each carrier’s codes to a short ordered list of states, map exceptions by cause, keep the raw code, text and timestamp, store times with an offset and version the mapping.

How often can I poll carrier tracking APIs?
It varies. FedEx allows 1,400 transactions per 10 seconds, Canada Post 20 tracking requests a minute by default, and DHL 250 calls a day for developers. UPS offers push alerts, and USPS does not publish a number.

Does Locus publish its status list?
Its published case says it harmonized every carrier’s status into one standard set, and its order API defines status and sub-status values. Its pages read do not publish a carrier-code mapping, so ask for one.