Order lifecycle

Once you have received an order, you report its progress back. This is an expected part of a correct integration, not an extra: technically the order is processed without these calls, but without them the courier is dispatched on wrong estimates and the store’s statistics degrade — preparation times, delays and acceptance rates end up describing something other than what happens in the restaurant.

The most important call is acceptance, with a preparation time set.

What changes when you report

What you report	What changes
Acceptance, with a preparation time	The courier is dispatched at the right moment, not too early.
Ready for pickup	The courier knows they can come in and collect.
Out for delivery	The customer sees the order as on its way.
Picked up by customer	The order closes correctly when the customer collects in person.

The biggest gain is the first: a realistic preparation time cuts courier waiting time in the restaurant.

How to report

One endpoint per transition:

PUT /api/v3/order-lifecycle/integrations/orders/{orderId}/accept/{storeId}
PUT /api/v3/order-lifecycle/integrations/orders/{orderId}/ready_for_pickup/{storeId}
PUT /api/v3/order-lifecycle/integrations/orders/{orderId}/out_for_delivery/{storeId}
PUT /api/v3/order-lifecycle/integrations/orders/{orderId}/customer_picked_up/{storeId}

Transition	When you send it	Available for
accept	You took the order into the POS.	any order
ready_for_pickup	The order is packed and waiting.	courier-collected orders
out_for_delivery	You left with it towards the customer.	marketplace orders
customer_picked_up	The customer collected it in person.	customer-collected orders

This is also the only way to transmit a preparation time.

The variant with the status in the request body is no longer accepted

There used to be a single endpoint taking the transition as a status in the body (POST /api/v3/order/stores/orders/status). Do not use it in a new integration, and migrate if you still do: it cannot carry the preparation time, which is exactly the part that matters.

Preparation time

On acceptance you can state when the order will be ready:

PUT /api/v3/order-lifecycle/integrations/orders/616342127/accept/gi20__001
Authorization: your-api-key
Content-Type: application/json

{
  "committedPreparationTime": "2026-02-02T19:20:30Z"
}

Rule	Detail
Format	ISO-8601 in UTC: YYYY-MM-DDThh:mm:ssZ.
Increase limit	It can be pushed out by at most 10 minutes beyond the existing estimate.
Accepted technically without it	The request goes through, but then acceptance says nothing about when the order will be ready — send it.

A failed validation does not show in the HTTP code

If committedPreparationTime fails validation, the order is still accepted and you still get 200. The difference is in the response body:

{
  "invalid-params": [
    {
      "name": "committedPreparationTime",
      "reason": "Committed preparation time is missing."
    }
  ],
  "title": "Your request parameters are not valid."
}

If you only look at the status code, you will believe the preparation time was recorded when it was in fact ignored. Check for invalid-params in the body.

If you report nothing

The order proceeds — not reporting does not block processing. But the effects accumulate silently: the courier arrives on generic estimates instead of your real time, and the store shows up in the statistics with times and rates that are not its own. Nothing flags this as an error, which is one more reason not to leave it for later.

The full specification of these operations is in the API reference.