Delivery status reference
The statuses that may appear in the status field of a delivery or webhook event. EXPRESS and LOGISTIC have different lifecycles — pick a tab below to see the statuses applicable to that category.
- EXPRESS
- LOGISTIC
Changed in v2. EXPRESS no longer emits a generic FAILED — it's split into FAILED_PICKUP and FAILED_DELIVERY so you can tell which leg failed without inspecting pickupAt. Update any status === "FAILED" branch. LOGISTIC is unchanged.
QUEUEING
Scheduled delivery is waiting for its pickup window. Will transition to ALLOCATING when the window opens.
ALLOCATING
Dash is finding the nearest available driver.
courier is null at this stage.PENDING_PICKUP
A driver has accepted the job but hasn't moved yet.
trackingURL becomes available from this status onward. Driver may still be re-assigned — re-assignment fires a new webhook with updated courier data.PICKING_UP
Driver is on their way to the pickup location.
ARRIVED_AT_PICKUP_POINT
Driver has arrived at the sender's location but hasn't collected the package yet.
PENDING_DELIVERY
Package has been picked up and is in an intermediate state before reaching IN_DELIVERY.
pickupAt and PICKUP_PROOF media are now present.IN_DELIVERY
Driver is en route to the recipient with the package in hand.
ARRIVED_AT_DESTINATION
Driver has arrived at the recipient's location but hasn't captured
DELIVERY_PROOF yet.COMPLETED
Driver captured
DELIVERY_PROOF at the destination. Terminal state.CANCELLED
Cancelled by the provider before the package was picked up — while status was ALLOCATING, PENDING_PICKUP, or PICKING_UP.
reason and reasonCode are populated. Terminal state.FAILED_PICKUP
Driver could not collect the package (sender unavailable, package not ready, address not found, etc.).
reason and an EB reasonCode are populated; pickupAt stays null and FAILED_PICKUP_PROOF media is captured. Nothing was collected, so there's no return leg. Terminal state.FAILED_DELIVERY
Driver had the package but could not complete the drop (recipient unavailable, COD refused, SLA exceeded, etc.).
reason and an EC reasonCode are populated; FAILED_DELIVERY_PROOF media is captured. May enter the return flow below instead of staying terminal. Terminal state otherwise.PENDING_RETURN
Failed delivery queued to go back to the sender. Only reachable from
FAILED_DELIVERY — a FAILED_PICKUP has nothing to return.IN_RETURN
Driver is en route back to the sender with the package.
ARRIVED_AT_RETURN_POINT
Driver has arrived back at the sender's location but has not handed the package over yet. Reached from
IN_RETURN. No media or reason is captured — the hand-back has not happened. Resolves as RETURNED if the sender accepts the package, or FAILED_IN_RETURN if they don't.FAILED_IN_RETURN
The return leg itself failed — the driver could not hand the package back (nobody reachable at the return address, the location was closed, an operational issue, not enough time left in the shift, weather). Reached from the return leg, after
IN_RETURN. reason and an ED reasonCode are populated and FAILED_RETURN_PROOF media is captured; courier stays populated because the driver is still holding the package. Not terminal — Dash Ops takes the package over from here. A re-attempted return surfaces later as a fresh PENDING_RETURN; that is not a direct transition, since ops handling sits in between.ON_HOLD
Package is parked with Dash Ops at a pitstop instead of staying on the driver — the hold state after a failed return. Reached from
FAILED_IN_RETURN, sometimes via internal hub-transfer steps you don't receive. The driver is released from the job, so courier is null; no hold-specific media or reason code exists. Not terminal — ops either re-attempts the return (a fresh PENDING_RETURN), completes the hand-back from the pitstop (RETURNED), or writes the package off (DISPOSED).RETURNED
Package handed back to the sender;
RETURN_PROOF media captured. recipient.actualRecipientName / actualRecipientRelation describe whoever signed for the return, not the original recipient. Terminal state.DISPOSED
Package written off — Dash Ops disposed of it rather than returning it to the sender. Reached from
ON_HOLD, or directly from a failure — FAILED_DELIVERY, and also FAILED_PICKUP, where nothing was collected in the first place. No disposal-specific media is captured. Terminal state.LOGISTIC has no QUEUEING (no scheduled-pickup queue), no ALLOCATING / PENDING_PICKUP (no driver-allocation phase), and no PICKING_UP (the warehouse hand-off replaces it). It also keeps the single FAILED status — the FAILED_PICKUP / FAILED_DELIVERY split is EXPRESS-only.
PREPARING
Delivery has been accepted by the system and is awaiting warehouse verification. Confirmation that the record exists.
VERIFIED
Package verified by ops at the warehouse and ready to be staged for the delivery leg.
NOT_VERIFIED
Manifest received by the ops team but the physical package wasn't received. Can transition back to
VERIFIED once the package arrives.PENDING_DELIVERY
Verified package staged and assigned for the delivery leg.
IN_DELIVERY
Driver is en route to the recipient. (No
trackingURL on LOGISTIC.)COMPLETED
Driver captured
DELIVERY_PROOF at the destination. Terminal state.FAILED
Drop could not complete.
reason and reasonCode are populated. Dash Ops may recover the delivery back to PENDING_DELIVERY for a retry, or route it into the return flow below. Otherwise terminal.PENDING_RETURN
Failed delivery queued to go back to the sender. Only reachable from a FAILED event where the package had already left the warehouse.
IN_RETURN
Driver is en route back to the sender with the package.
FAILED_IN_RETURN
The return leg itself failed — the package could not be handed back (nobody reachable at the return address, the location was closed, an operational issue, weather). Reached from the return leg, after
IN_RETURN. reason and an ED reasonCode are populated and FAILED_RETURN_PROOF media is captured. Not terminal — Dash Ops takes the package over from here. A re-attempted return surfaces later as a fresh PENDING_RETURN; that is not a direct transition, since ops handling sits in between.ON_HOLD
Package is parked with Dash Ops at a pitstop instead of staying on the driver — the hold state after a failed return. Reached from
FAILED_IN_RETURN, sometimes via internal hub-transfer steps you don't receive. The driver is released from the job, so courier is null; no hold-specific media or reason code exists. Not terminal — ops either re-attempts the return (a fresh PENDING_RETURN), completes the hand-back from the pitstop (RETURNED), or writes the package off (DISPOSED).RETURNED
Package handed back to the sender;
RETURN_PROOF media captured. recipient.actualRecipientName / actualRecipientRelation describe whoever signed for the return, not the original recipient. Terminal state.DISPOSED
Package written off — Dash Ops disposed of it rather than returning it to the sender. Reached from
ON_HOLD, or directly from any FAILED, whether or not the package had left the warehouse. No disposal-specific media is captured. Terminal state.