Ciclul de viață

După ce ai primit o comandă, îi raportezi înapoi evoluția. Este o parte așteptată a unei integrări corecte, nu un supliment: din punct de vedere tehnic comanda se procesează și fără aceste apeluri, dar fără ele curierul este trimis pe estimări greșite, iar statisticile magazinului se deteriorează — timpi de preparare, întârzieri și rate de acceptare ajung să descrie altceva decât se întâmplă în restaurant.

Apelul cel mai important este acceptarea, cu un timp de pregătire setat.

Ce se schimbă când raportezi

Ce raportezi	Ce se schimbă
Acceptarea, cu un timp de pregătire	Curierul este trimis la ora potrivită, nu prea devreme.
Gata de ridicare	Curierul știe că poate intra să preia comanda.
Plecat spre client	Clientul vede comanda ca fiind pe drum.
Ridicat de client	Comanda se închide corect când clientul vine personal.

Cel mai mare câștig este primul: un timp de pregătire realist reduce așteptarea curierului în restaurant.

Cum se raportează

Un endpoint pentru fiecare tranziție:

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}

Tranziție	Când o trimiți	Disponibilă pentru
accept	Ai preluat comanda în POS.	orice comandă
ready_for_pickup	Comanda e împachetată și așteaptă.	comenzi ridicate de curier
out_for_delivery	Ai plecat cu ea spre client.	comenzi marketplace
customer_picked_up	Clientul a ridicat-o personal.	comenzi ridicate de client

Aceasta este și singura variantă prin care poți transmite un timp de pregătire.

Varianta cu status în corpul cererii nu mai este acceptată

A existat și un singur endpoint care primea tranziția ca status în corp (POST /api/v3/order/stores/orders/status). Nu îl folosi într-o integrare nouă și migrează dacă îl mai folosești: nu poate transmite timpul de pregătire, adică exact partea care contează.

Timpul de pregătire

La acceptare poți spune când va fi comanda gata:

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

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

Regulă	Detaliu
Format	ISO-8601 în UTC: YYYY-MM-DDThh:mm:ssZ.
Limită de creștere	Poate fi mărit cu cel mult 10 minute față de estimarea existentă.
Acceptat tehnic și fără el	Cererea trece, dar atunci acceptarea nu spune nimic despre când e gata comanda — trimite-l.

Validarea eșuată nu se vede în codul HTTP

Dacă committedPreparationTime nu trece validarea, comanda este totuși acceptată și primești tot 200. Diferența este în corpul răspunsului:

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

Dacă te uiți doar la codul de status, vei crede că timpul de pregătire a fost înregistrat, când de fapt a fost ignorat. Verifică prezența lui invalid-params în corp.

Ce se întâmplă dacă nu raportezi nimic

Comanda merge mai departe — lipsa raportării nu blochează procesarea. Dar efectele se acumulează tăcut: curierul ajunge după estimări generice în loc de timpul tău real, iar magazinul apare în statistici cu timpi și rate care nu sunt ale lui. Nimic nu semnalează asta ca eroare, motiv în plus să nu o lași pe „mai târziu“.

Specificația completă a acestor operații este în referința API.