System Components
Delivery Status
Nash integrates with hundreds of fleets, and we normalize all their statuses into a list of Nash Delivery Statuses. In this page, we explain these statuses and highlight a few things that are important to know when working on processing the Nash status updates.
Delivery Status List
For delivery status. The values are:| Status | Description |
|---|---|
CREATED | if you see this value in the DeliveryStatus object then this means that the delivery order has registered with the provider and is therefore “created”. In the frontend, currently a job status can also be created if its TaskStatus is Created (which happens before it’s sent to the provider). |
SCHEDULED | the provider has scheduled the order. |
NOT_ASSIGNED_DRIVER | provider acknowledges the order but has not assigned a driver to it yet. |
ASSIGNED_DRIVER | a driver has been assigned to the order. |
STARTED | the delivery has started. This status is not that common. |
PICKUP_ENROUTE | the driver is en route to the pickup point. |
PICKUP_ARRIVED | the driver has arrived at the pickup point. |
PICKUP_COMPLETE | the driver has completed the pickup. |
DROPOFF_ENROUTE | the driver is en route to the dropoff point. |
DROPOFF_ARRIVED | the driver has arrived at the dropoff point. |
RETURN_IN_PROGRESS | the driver is en route to the pickup point with intentions to return the package (e.g., delivery containing alcohol cannot be delivered due to failed age verification and needs to be returned to the store) |
Terminal Statuses
Once a delivery reaches this status, it will not change again| Status | Description |
|---|---|
DROPOFF_COMPLETE | the driver has dropped off the order. |
CANCELED_BY_CUSTOMER | the order was canceled by the Nash customer via the portal or API. |
CANCELED_BY_PROVIDER | the order was canceled by the provider. |
CANCELED_BY_NASH | the order was canceled by a member of the Nash team or the Nash system. |
CANCELED_BY_AUTO_REASSIGN | the order was canceled by the Nash auto-reassignment functionality. |
RETURNED | the provider has returned the order. |
EXPIRED | the order has expired. |
FAILED | the provider marked the order as failed. You can check the task.failure_reason for more notes |
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 fleet 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 Critical Path status.
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 Critical Delivery Status Path defined earlier.
- Critical Path Delivery Statuses may be inferred by Nash.