Listening for Order Events

Ingest order details to your in-store system and respond to order status updates.

Once you have configured the Order Events webhook, Deliveroo will begin notifying your integration about order-related events using the Order Events Webhook Callback.

In response, your integration must do the following:

1. Notify the site

  • For tablet-based sites, you will need to validate the order event, translate it into a format that the till will understand and then send the order to the restaurant till.

  • For tablet-less sites, for each new order, you will need to validate the order event, translate it into a format that the till will understand and then send the order to the till to inform the site about it and allow them to accept/reject it. Also, you must inform the till about every order's status update.

    How you implement this depends on your internal system.

2. Notify Deliveroo of a successful or failed order injection

  • For tablet-based sites, after you successfully process the first order webhook call (of any type) with "accepted" status being present in the order status log, you have to notify us by sending a proper sync status to Deliveroo's sync_status endpoint.

  • For tablet-less sites, after the order is accepted/rejected, you don't need to do anything more! We treat sending us a request to accept/reject an order as a sufficient notification.

Expected Responses

Your Responses

After verifying and successfully processing the payload, the webhook endpoint in your integration must respond with an HTTP status 200 OK to our requests.

Deliveroo Responses

For tablet-based sites, Deliveroo must respond with 200 OK in response to your request to the Create Sync Status endpoint.

For tablet-less sites, Deliveroo must respond with 204 No Content in response to your request to the Update Order Status.

Failures

❗️

Auto-rejection of Unacknowledged Tablet-less Orders

If you fail to accept/reject an order for a tablet-less site, Deliveroo will automatically reject it. The auto-rejection time is seven or more minutes, depending on the market. A tablet-less site will be automatically closed after several auto-rejections.

In case Deliveroo receives an HTTP status 200 OK from the webhook endpoint, yet your integration fails to send:

  • A sync status back within 3 minutes, then Deliveroo will send a message to the tablet requesting the staff check that the order made it to the in-store system. This is valid for tablet-based sites only.

  • A successful Update Order Status request, then Deliveroo will reject the order. This is valid for tablet-less sites only.

A webhook can indicate failure by responding with HTTP status 4xx or 5xx.

Retry Logic

Deliveroo will retry webhook calls, but the exact logic varies between the type of order and event:

  • For ASAP orders, Deliveroo will retry the request for up to 6 minutes. It only applies to the order.new event.

  • For scheduled orders, Deliveroo will retry the request for up to 30 minutes. It only applies to the order.new event.

  • For order.status_update events, Deliveroo will retry the request for up to 10 minutes.

If all retries fail, then:

  • For tablet-based sites, Deliveroo will send a message to the tablet requesting the staff to input the order manually into the in-store system.

  • For tablet-less sites, Deliveroo will reject the order.

Retry Logic for POS Legacy Webhook

Deliveroo will retry the webhook call for up to 3 minutes for both events - new_order and cancel_order.

If all retries fail for the new_order event, then Deliveroo will send the order back to the tablet to be manually inserted into the in-store system.