Order Integration

Once configured, Deliveroo will begin notifying you about order-related events via the Order Events webhook. You may also opt-in to receive events related to rider status through an additional Rider Events webhook.

Whether your site is tablet-less or tablet-based, your integration will have to follow one of the two flows described below.

To switch a site to tablet-less mode, please contact your account manager.

📘

Webhooks?

A webhook is a mechanism that calls your HTTPS endpoint when certain event occurs. In this case, the event is the Deliveroo order or a change related to it and the HTTPS call is what informs your till about order details.

Your webhook should be an HTTPS endpoint which listens to events from Deliveroo.

Tablet-less Flow

1. A customer places an order through Deliveroo's website or app.
2. We send an event, order.new, about it via the Order Events webhook with the order's status as placed.
3. The site accepts (or rejects) this order by calling our Update Order Status endpoint.
4. Via the Order Events webhook, we send you an order.status_update event presenting the new order status. If you have the legacy POS webhook configured and accepted the order, you'll receive another event, new_order.
5. If the order is of scheduled type, you have to send another request to our Update Order Status endpoint to confirm it before the site starts to prepare it. After your call succeeds, we'll send you a notification about the status change.
6. If customer wants to cancel an order then we will notify you about order's status change via Order Events webhook (order.status_update event) and POS (Legacy) webhook (cancel_order event). Please see Canceled Orders for more details.

❗️

Order Preparation

• All orders must be accepted (with accepted status present in the status_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 until start_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

Tablet-based Flow

1. A customer places an order through Deliveroo's website or app.
2. The order is shown on the site's tablet. At the same time, we send an order.new event about it via the Order Events webhook with the order's status as placed or accepted .
3. A site staff accepts/rejects the order from the tablet.
4. Via the Order Events webhook, we send you an order.status_update event presenting the new order status. If you have the legacy POS webhook configured and accepted the order, you'll receive another event, new_order.
5. We wait for you for three minutes to send us the Sync Status request. The sync status indicates that your integration injected the order successfully into the site's in-store system.
6. If the order is of scheduled type, you have to manually confirm it from the tablet before the site starts to prepare it. After your call succeeds, we'll send you a notification about the status change.
7. If customer wants to cancel an order then we will notify you about order's status change via Order Events webhook (order.status_update event) and POS (Legacy) webhook (cancel_order event). Please see Canceled Orders for more details.

New orders need to reach the kitchen / site without any delays or buffers

Deliveroo calculates dynamic prep times for every order to ensure smooth operations. We do this using an algorithm called the prep time model.

It is very important to avoid introducing any artificial delays, holds or buffers to the prep times calculated by the Deliveroo prep time model.

🚧

Adding artificial buffer times or delays before you release orders to the kitchen / site will over-inflate your prep times, and reduce your orders on Deliveroo

Make sure to avoid introducing any delays in your API, integrator, middleware, POS or KDS systems

The diagram below explains why buffer times will over-inflate your prep times. If you have concerns about managing your orders and feel like you need a buffer then please contact the Deliveroo integration team for further information here

Scope of Implementation

To use our Order API, you need to fulfill the below requirements. You don't need to support every endpoint and webhook callback, but we recommend that you do for the best experience.

🚧

Required

To be compatible with our Order API, you need to integrate the following features:

• Listen for events through an Order Events webhook endpoint in your integration. The endpoint must verify and process payloads sent to your integration, as described by tablet-less or tablet-based flows.
• Check and update Order Events webhook configuration through Get and Update.
• Accept/reject orders through Update Order Status endpoint for tablet-less restaurants.
• Send sync status through Create Sync Status for an Order endpoint for tablet-based restaurants.

👍

Recommended

To make the most out of your Deliveroo integration, we recommend you integrate the following features:

• Listen for events through a Rider Event webhook endpoint in your integration. The endpoint must verify and process payloads sent to your integration.
• Check and update Rider Events webhook configuration through Get and Update.
• Get order details using Get Single Order Details and Get Orders endpoints.
• Inform Deliveroo how the order preparation goes through the Create Preparation Stage endpoint.

❗️

POS Webhook

The POS (Legacy) webhook (the one receiving new_order and cancel_order events) is deprecated. No further development will take place for it. Please refer to the new Order Events and Rider Status webhooks.

View POS API documentation here