Order statuses
The status dictionary, which action is possible in which status, and the undeliverable outcome.
Status dictionary
The status field of an order carries one of the values below. An order is created by the payment gate; forward transitions are written by the business (or by its point-of-sale software on its behalf). delivered and cancelled are terminal.
| Alan | Tip | Açıklama |
|---|---|---|
pending | both verticals | The order reached the business and awaits acceptance. If not accepted it is cancelled automatically after 12 minutes (Order lifecycle). |
preparing | both verticals | On a restaurant, via accept; the preparation time is fixed on acceptance. On Çarşı, picking is in progress or closed; whether picking is closed is in the picking.completed field. |
ready | restaurant | Via ready. Preparation is finished; courier hand-off or your own delivery starts after this. |
confirmed | Çarşı | Via accept. This is the status before picking starts; when the first item result is written the order becomes preparing. |
on_the_way | both verticals | Via dispatch. |
delivered | both verticals | Via deliver. |
cancelled | both verticals | Via cancel or by the platform. The reason is in the cancelReason field. |
Actions versus statuses
When writing a status you send the action, not the target status: accept, ready, dispatch, deliver, cancel. Each action corresponds to a transition. A transition that is not listed returns 409 invalid_transition with the allowed field. Statuses the server writes itself (payment, automatic cancellation) cannot be sent as actions.
| Alan | Tip | Açıklama |
|---|---|---|
pending | accept · cancel | |
preparing | ready · cancel | |
ready | dispatch · cancel | |
on_the_way | deliver · cancel |
| Alan | Tip | Açıklama |
|---|---|---|
pending | accept · cancel | |
confirmed | cancel; also ready if picking is closed | |
preparing | cancel; also ready and dispatch if picking is closed | |
on_the_way | deliver · cancel |
On Çarşı, ready does not change the status; it confirms that picking is closed. Before picking is closed, ready and dispatch return 409 picking_incomplete.
Time fields
| Alan | Tip | Açıklama |
|---|---|---|
createdAt | date-time | Order created. |
updatedAt | date-time | The last change moment; used for sync with updatedSince. |
prep.readyAt | date-time | On a restaurant, the ready time fixed on acceptance. |
deliveryFailed.at | date-time | The time of the undeliverable outcome. |
For a transition reported late, send the actual time in occurredAt (applied on restaurants only; on Çarşı the transition is written at the moment the request arrives).
Undeliverable
If the courier cannot reach the customer or the address is wrong, an order on the way can only be cancelled with the reason customer_unreachable (customer unreachable) or invalid_address (wrong or incomplete address). These reasons are accepted only while the order is on_the_way; an order on the way cannot be cancelled with another reason.
curl -X POST "https://api.supergelsin.com/api/partner/v1/orders/cm_ornek_siparis/status" \
-H "Authorization: Basic $(printf '%s:%s' "$API_KEY" "$API_SECRET" | base64)" \
-H "X-Integrator: Ornek POS" \
-H "X-Operator: kasiyer_01" \
-H "Content-Type: application/json" \
-d '{ "action": "cancel", "reasonCode": "customer_unreachable", "occurredAt": "2026-01-31T19:42:00+03:00" }'On the order object, status becomes cancelled; cancelReason carries the reason and deliveryFailed the outcome. On a restaurant, deliveryFailed.completedSale is true exactly when payment.channel is online: if true the sale is complete, it is not cancelled at the till and is closed as a sale paid online; the event arrives as order.updated. On Çarşı, completedSale is always false, for an online payment the whole amount is refunded to the customer and the event arrives as order.cancelled; the return is confirmed with POST /orders/{id}/return. Whether the reason is recorded in the business's performance is in the affectsPerformance field of the GET /cancel-reasons response.