The Business Orders endpoints allow authenticated business roles to view, filter, and act on incoming orders. Every status transition is validated against both the caller’s permissions (e.g.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/CRISTIANCAMACH34/Zippi/llms.txt
Use this file to discover all available pages before exploring further.
orders.accept, orders.reject) and the order FSM before the change is persisted. Each transition is atomically written to historial_estados_pedido with a correlation_id for full traceability.
Order states and business-side FSM transitions
| Transition | Permission required | Roles that hold it |
|---|---|---|
pending → accepted | orders.accept | business_owner, business_admin, business_branch_admin, waiter |
pending → rejected | orders.reject | business_owner, business_admin, business_branch_admin, waiter |
accepted → preparing | orders.prepare | business_owner, business_admin, business_branch_admin, kitchen_staff |
preparing → packed | orders.pack | business_owner, business_admin, business_branch_admin, kitchen_staff |
Every status transition writes an immutable row to
historial_estados_pedido. The row stores estado_anterior, estado_nuevo, actor_tipo, actor_id, observacion, correlation_id, and trace_id. This audit trail cannot be modified or deleted via any API endpoint.GET /api/v1/business/orders
Returns a paginated list of orders for the authenticated business scope. Supports filtering by status, branch, and date range.Filter by order status. Accepted values:
pending, accepted, preparing, packed, picked_up, in_transit, delivered, closed, cancelled, failed.Page number, 1-indexed.
Records per page. Recommended maximum: 100.
Filter orders for a specific branch. Required when the caller is a
business_branch_admin (scope is enforced automatically).ISO 8601 date string (e.g.
2024-06-01). Returns orders created on or after this date.ISO 8601 date string (e.g.
2024-06-30). Returns orders created on or before this date.200 OK
GET /api/v1/business/orders/:id
Returns the full detail of a single order, including line items, status history, courier assignment, and incidents.Internal primary key of the order.
Human-readable order reference code, unique across the platform.
Current FSM state of the order.
Payment method:
cash, nequi, wompi, transfer.Delivery fee in centavos.
Estimated product subtotal in centavos at order creation time.
Confirmed product subtotal in centavos, set when the business confirms the order.
Final charged amount in centavos including service fee and adjustments.
Ordered list of all FSM state transitions for audit purposes.
PATCH /api/v1/business/orders/:id/status
Advances the order through the FSM to a new state. The service layer validates the transition against the FSM rules and the caller’s permissions before persisting.Target FSM state. Must be a valid transition from the order’s
estado_actual. Accepted business-side values: accepted, rejected, preparing, packed.Optional human-readable justification for the transition. Required when
new_status is rejected or cancelled. Stored in historial_estados_pedido.observacion.200 OK
The
correlation_id returned in the response is the same value written to historial_estados_pedido. Use it to cross-reference log lines, trace distributed events, and correlate audit entries across services.POST /api/v1/business/orders/:id/incident
Reports an operational incident on a specific order (e.g. missing item, wrong product, customer not present). Returns201 Created. Stored in incidencias_pedido.
Incident category. Common values:
producto_faltante, producto_incorrecto, cliente_ausente, pedido_dañado, otro.Full description of the incident. Stored verbatim for support and dispute resolution.
201 Created
GET /api/v1/business/kitchen/queue
Returns the active kitchen comanda queue for the authenticated branch scope, ordered by creation time. Designed for the kitchen display screen.kitchen_staff, business_owner, business_admin, or business_branch_admin (module: orders).
The response surfaces orders in accepted or preparing states with their line items expanded, so the kitchen screen can display preparation instructions without additional round-trips.
GET /api/v1/business/waiter/floor
Returns the floor map view for the waiter surface: tables with their active orders, seat counts, and pending items that need attention.waiter, business_owner, business_admin, or business_branch_admin (module: orders).
The waiter floor view aggregates orders by table and surfaces pending-acceptance and in-progress items so the front-of-house team can triage service without leaving the floor map.