PATCH /api/orders/:id/status
Updates an order’s status. Status transitions must follow the defined workflow.Authentication
Requiresorders:update permission (waiter, cashier, branch_manager, org_admin).
Path Parameters
UUID of the order to update
Request Body
New status for the order. Must be a valid transition from the current status.Options:
pending, confirmed, preparing, ready, served, completed, cancelledAllowed Status Transitions
Orders can only transition to specific statuses based on their current state:| Current Status | Allowed Next Statuses |
|---|---|
pending | confirmed, preparing, cancelled |
confirmed | preparing, cancelled |
preparing | ready, cancelled |
ready | served |
served | completed |
completed | (terminal state) |
cancelled | (terminal state) |
Attempting an invalid transition will return a 400 error.
Response
Indicates if the request was successful
The updated order object
Error Responses
false when an error occursError details
Example Response
Error Example - Invalid Transition
Completed Status Side Effects
When an order is transitioned tocompleted status, the following side effects occur:
Loyalty Points
If the order has an associated customer, loyalty points are awarded based on the order total
WebSocket Notification
When order status is updated, WebSocket events are broadcast to:branch:{branchId}- All branch staffbranch:{branchId}:kitchen- Kitchen displayssession:{sessionId}- Customer apps (if order has a table session)
Related Endpoints
Kitchen Management
Update individual order item status (used by kitchen staff)
Notes
- Status transitions are validated server-side based on
ORDER_STATUS_TRANSITIONS - Updating to
completedtriggers loyalty points calculation and inventory deduction - Kitchen staff typically use item-level status updates rather than full order status changes
- The
updated_attimestamp is automatically set to the current time