This allows a POS to update the status of an order.
|Id assigned by the POS, may be the same as the orderId||string|
|Status to be updated||integer|
Some POS systems use a separate Id for the order Id
_id and the receipt that was printed for it (
receiptId). The latter is usually something human-friendly, while the former can be a long internal ID if a separate
receiptId does not apply, it's a good practice to default the value to that of the
orderId. The receiptId is a required parameter.
When a status is not supported, it can be skipped. It is, however, crucial to sync statuses back. Some channels will only mark the order successful when the status is
ACCEPTED or higher, and some channels take the
PREPARING state into account. The more data you can provide, the better the experience for the customer.
(For some channels, such as Takeaway.com, orders will not be retrieved if they aren't put to status
PRINTED. In this case, their support will call the restaurant if it takes more than five minutes to reach that status).
If you want to specify a reason for a status change (for instance when it failed), you can set the reason property.
See the link below for all statuses and their corresponding integer value.
NB: There is no specific sequence of statuses as they will correspond to your POS workflow/processes. Deliverect does need to know when all POS processes have completed and are in the
FINALIZEDdoesn't necessarily mean that the order has been delivered to the end customer!
This is a status sent to the POS when we ask for it to be cancelled.
Such a request comes in at the orders webhook endpoint, as an order with the
CANCEL status. For more information and an example, look at the documentation for the Orders webhook. In the case of an order with status
CANCEL, Deliverect will resend that order to the POS, with the same
channelOrderDisplayId (information available on the Orders webhook page).
Your POS should never send an order status update request with this status to Deliverect.
This means that the order was canceled by the POS.
In case of an order with the CANCEL status, Deliverect will resend that order to the POS, with the same channelOrderId and channelOrderDisplayId (information at Orders webhook).
An example of an order status update request to Deliverect to confirm cancellation by the POS can be seen on the right. Select the example from the drop-down box.
- On the POS side, it should be made very clear to the user that the order needs to be canceled. Printing new tickets for orders that indicate the order was canceled (so the kitchen knows they don't need to prepare the order) is a correct way of doing this. Whether a canceled order should be voided or not is up to the logic of the POS.
- The POS should send Deliverect a status
CANCELED(110) back, so Deliverect knows the order has been canceled in the POS.