Skip to main content
Nash integrates with 80+ delivery providers and normalizes all their statuses into a single list of Nash delivery statuses. Build your status handling against this list and what follows about ordering and inference.
This page writes statuses in UPPERCASE for readability. On the wire — the status and statusHistory fields in API responses, and webhook event names — the same lifecycle arrives as lowercase snake_case values: DROPOFF_COMPLETE here is dropoff_complete in a payload.

​
Delivery status list

The delivery status values are:

​
Terminal statuses

Once a delivery reaches one of these statuses, it will not change again.

​
Guaranteed status order

Nash guarantees the following path if the delivery is completed.
CREATED -> ASSIGNED_DRIVER -> PICKUP_ENROUTE -> PICKUP_ARRIVED -> DROPOFF_ENROUTE -> DROPOFF_ARRIVED -> DROPOFF_COMPLETE This means if a delivery reaches DROPOFF_COMPLETE we guarantee the other statuses before that will exist in the same order presented. Note you can have more statuses than these, but they will preserve their relative order and will always exist. We do this by inferring some statuses from providers, even if they do not provide them. For example, if a provider doesn’t support the Dropoff Arrived status but they send us a Dropoff Complete one, then we will inject the Dropoff Arrived status right before adding Dropoff Complete. This helps our API partners build workflows on top of the guaranteed status order.

​
Important to know

  • Different providers will support different subsets of the statuses above. It’s important to know this when building workflows on top of the statuses above.
  • Nash does not guarantee the order in which providers will send us the statuses, outside of the guaranteed status order defined earlier.
  • Statuses in the guaranteed status order may be inferred by Nash.

Webhooks

Receive these status transitions as real-time events on your endpoint.

How Nash works

The delivery lifecycle these statuses move through, end to end.