This webhook is used to let you know that there's a new order or a status update of an existing order. In order to receive these events, you need to have a configured Order Events webhook. If we receive an error in the response then we'll try to retry the callback:
- up to 6 minutes for ASAP orders,
- up to 30 minutes for scheduled orders,
We share an order event in our payloads. The following are all the valid values for it.
Order Status | Description |
---|---|
placed | Order is placed in our system. |
rejected | Order is rejected by site or automatically rejected due to lack of reaction from the restaurant. |
accepted | Order is accepted by site. |
confirmed | For scheduled orders only. Site has confirmed that they started preparing the order. |
canceled | Order was canceled by site or customer. |
We'll send you this payload after a new order is placed or updated. This requires a configured Order Events webhook URL.
Keep in mind that while every attempt is made to make callbacks in the order they occurred and in a timely manner, neither can be absolutely guaranteed. It is also possible to receive the same callback more than once. The status log should be treated as the source of truth when it comes to the order of the statuses.
Please consult Fulfillment Types page in Guides and see examples of requests on the right. See also other order types:
Order Preparation
- All orders must be accepted (with
accepted
status present in thestatus_log
in the event) before they are prepared.- For the vast majority of orders, the time you receive the order will be almost equal to the
start_preparing_at
timestamp.- Sometimes
start_preparing_at
may be far in the future (for example scheduled orders or when the site is close to closing). In these situations we recommend you wait untilstart_preparing_at
before printing or showing the order in the kitchen- For the avoidance of doubt: preparation time is inclusive of any time required to accept the order