This allows a POS to update the status of an order.

Required Parameters

Parameter

Meaning

Type

orderId

The _id that was sent to the POS order webhook

string

receiptId

Id assigned by the POS, may be the same as the orderId

string

status

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.

The table below lists statuses and their corresponding integer value. 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 Finalized state.

Deliverect status tag

Description

Integer value

PARSED (system status)

received and parsed by Deliverect

1

RECEIVED (system status)

received by POS

2

NEW

received by POS and receipt is created

10

ACCEPTED

accepted/confirmed

20

SCHEDULED (system status)

order has been received in Deliverect and is 'buffered', awaiting POS injection based on 'average preparation time' and 'pickup time'

25

DUPLICATE (system status)

order has been received multiple times on the POS due to a technical error

30

PRINTED

printed

40

PREPARING

in preparation

50

PREPARED

is prepared

60

READY FOR PICKUP

ready for pickup

70

IN DELIVERY

en route to customer

80

FINALIZED

finalized, order is fully handled and no further status updates are coming

90

AUTO FINALIZED

accepted by POS, but any other status updates unsupported by POS (to be avoided at all costs!)

95

CANCEL (system status)

should be voided. This status is applied by online channels when an order should be voided on the POS

100

CANCELED

has been voided on POS

110

FAILED

failed

120

POS RECEIVED FAILED

not received by POS

121

PARSE FAILED

parsing failed

124

DUPLICATE should only be used if the order is already in the POS and was (accidentally) submitted a second time.

FINALIZED means that the order is finalised in the POS.

❗️

Note that FINALIZED doesn't necessarily mean that the order has been delivered to the end customer!

FAILED is a status that should be used when the POS could not be reached, or when an order could not be processed correctly. For example, when a product is available on the merchant's online store but deleted in their POS account.

CANCEL vs CANCELED

CANCEL

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 channelOrderId and channelOrderDisplayId (information available on the Orders webhook page).

Your POS should never send an order status update request with this status to Deliverect.

CANCELED

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.

How should your POS handle this?

  1. 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.
  2. The POS should send Deliverect a status CANCELED (110) back, so Deliverect knows the order has been canceled in the POS.
Language
Authentication
OAuth2
Click Try It! to start a request and see the response here!