LOGISTIC

Warehouse-verified, multi-leg delivery. The Dash Ops team checks the physical package at the warehouse before dispatch. There is no driver-allocation phase — instead, the package goes through VERIFIED / NOT_VERIFIED verification states.

⚠

Deprecation — service-category create path. Creating deliveries on the shared POST /v1/deliveries endpoint (where the category is chosen via the serviceCategory field) is deprecated. Dedicated category paths are replacing it — EXPRESS already uses POST /express/v1/deliveries. The legacy shared path will be obsoleted on 21 November 2026; confirm the LOGISTIC create path with the Dash team before that date.

When to use LOGISTIC

Use serviceCategory: "LOGISTIC" when:

• The package is handed off to Dash Ops at a warehouse (not picked up from a partner location).
• You need the ops team to physically verify the package before delivery is dispatched.
• The delivery may involve multiple legs (warehouse → hub → final mile) — though the provider-visible contract only surfaces the legs above.

Service type

SAME_DAY

Currently the only LOGISTIC service type.

State machine

Transitions

PREPARING → VERIFIED / NOT_VERIFIED

Dash Ops checks the physical package at the warehouse. VERIFIED if received and confirmed; NOT_VERIFIED if the manifest arrived but the package did not.

NOT_VERIFIED → VERIFIED

Ops re-checks and confirms the package once it physically arrives.

VERIFIED → PENDING_DELIVERY

Package is staged and assigned for the delivery leg.

PENDING_DELIVERY → IN_DELIVERY

Driver is en route to the recipient.

IN_DELIVERY → COMPLETED

Delivered and proof captured. Terminal.

IN_DELIVERY → FAILED

Drop could not complete. Dash Ops may recover the delivery back to PENDING_DELIVERY for a retry, or route it into the return flow (PENDING_RETURN → IN_RETURN → RETURNED, or FAILED_IN_RETURN if the hand-back fails). Otherwise terminal.

IN_RETURN → FAILED_IN_RETURN

The return leg itself failed — nobody reachable at the return address, the location was closed, an operational issue, weather. reason and an ED reasonCode are populated and FAILED_RETURN_PROOF is captured. Not terminal — Dash Ops takes the package over from here.

FAILED_IN_RETURN → ON_HOLD

Ops parked the package at a pitstop and released the driver from the job. Not terminal — from here ops re-attempts the return (fresh PENDING_RETURN), hands it back at the pitstop (RETURNED), or writes it off (DISPOSED).

ON_HOLD / FAILED → DISPOSED

Package written off instead of returned — reachable from a hold, or straight from any FAILED, whether or not the package had left the warehouse. Terminal.

LOGISTIC-only webhook statuses

These are emitted only when serviceCategory: "LOGISTIC":

• VERIFIED — package verified by ops at the warehouse; awaiting driver assignment.
• NOT_VERIFIED — manifest received, package not physically received.

Differences from EXPRESS

	EXPRESS	LOGISTIC
Verification	None — driver collects directly	Ops verifies the package at the warehouse
Allocation	ALLOCATING → PENDING_PICKUP	No allocation phase
trackingURL	Present from PENDING_PICKUP	Not emitted
PICKUP_PROOF media	Captured by driver	Not captured
serviceType	INSTANT, SAME_DAY	SAME_DAY only
Cancellation	Provider may cancel in ALLOCATING / PENDING_PICKUP	No provider-side cancel — flow is driven by ops
Create path	POST /express/v1/deliveries	POST /v1/deliveries

Endpoints

LOGISTIC shares the quote, read, cancel, and notify endpoints with EXPRESS. The create-delivery path is the legacy generic one — /express/v1/deliveries is EXPRESS-only.

POST /v1/deliveries/quotes

Pre-flight quote with serviceCategory: "LOGISTIC". See Get delivery quote.

POST /v1/deliveries

LOGISTIC create path (with serviceCategory: "LOGISTIC"). Same body shape as the EXPRESS create; origin coordinates are optional for LOGISTIC. Deprecated — this shared path is obsoleted 21 Nov 2026; coordinate the replacement path with the Dash team.

GET /v1/deliveries/{deliveryID}

Read current state. See Get delivery details.

Gotchas

ⓘ

LOGISTIC's verification phase is operated by the Dash Ops team, not by your integration. You'll see VERIFIED / NOT_VERIFIED webhooks but you don't drive those transitions. NOT_VERIFIED can transition back to VERIFIED when the physical package finally arrives.

• No trackingURL. If you display a live tracking link to recipients, only do it on EXPRESS deliveries.
• No PICKUP_PROOF. LOGISTIC's POD bundle has DELIVERY_PROOF only on COMPLETED (plus FAILED_PICKUP_PROOF / FAILED_DELIVERY_PROOF on FAILED, depending on the leg).
• Single FAILED status. The FAILED_PICKUP / FAILED_DELIVERY split introduced in the v2 payload is EXPRESS-only — LOGISTIC still reports both legs as FAILED, distinguished by the reasonCode prefix and the media type.
• origin.coordinates is optional for LOGISTIC (the warehouse pickup is implicit). EXPRESS requires coordinates.
• No provider-side cancellation. Cancellation in LOGISTIC is driven by Dash Ops; your DELETE call won't cancel a LOGISTIC delivery once it's past PREPARING.