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. Otherwise 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_PROOF on FAILED).
• 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.