Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/123048152-JJDS/CafeteriaPM_S203/llms.txt

Use this file to discover all available pages before exploring further.

Dining table management in CafeteriaPM is dynamic — a table’s status is derived in real time from whether it has an active order. There is no separate status column on the mesas table; instead, every time table data is requested, the API queries the pedidos table to determine the current occupancy state. This means table status is always consistent with the order system and cannot drift out of sync.

​
Table Status

Each MesaOut response object includes a computed estado field with one of three values:
StatusMeaning
disponibleNo active orders are linked to this table
ocupadaThe table has an active order in pendiente, en_preparacion, listo, or entregado state
reservadaThe table has an order in the special reservado state
Every MesaOut also includes pedido_activo_id — the ID of the active order, or null if the table is disponible. Use this ID to quickly navigate to the relevant order without a separate lookup. 
{
  "id": 5,
  "numero": 5,
  "capacidad": 4,
  "estado": "ocupada",
  "pedido_activo_id": 47
}

​
Table Endpoints

​
Listing Tables

GET /mesas/ returns all tables with their live computed status. Any authenticated user.

​
Get by Number

GET /mesas/por-numero/{numero} looks up a table by its human-readable display number rather than the internal database ID. Useful for POS interfaces where staff navigate by table number. Any authenticated user. 
GET /mesas/por-numero/5
Returns 404 if no table with that display number exists.

​
Get by ID

GET /mesas/{mesa_id} looks up a table by its internal ID. Any authenticated user.

​
Creating Tables

POST /mesas/ (admin only) — Creates a new dining table. Returns 400 if a table with the same numero already exists. 
{"numero": 5, "capacidad": 4}
FieldTypeDescription
numerointegerThe display number shown to staff (must be unique)
capacidadintegerSeat capacity (must be > 0)

​
Deleting Tables

DELETE /mesas/{id} (admin only) — Permanently removes a table. Returns 400 if the table is currently ocupada or reservada, including the active order ID in the error message so staff can resolve it first. Also blocked if the table has any historical orders associated with it.

​
Occupancy Operations

These action endpoints drive the table lifecycle during a shift.

​
Occupy a Table

PATCH /mesas/{id}/ocupar (admin, mesero) Creates an empty pendiente order on the table as a placeholder. Returns 400 if the table already has an active order. 
{"message": "Mesa ocupada correctamente", "pedido_id": 42}

​
Release a Table

PATCH /mesas/{id}/liberar (admin, mesero, caja) Forces the table’s active order to pagado state, bypassing the normal payment flow. Use this when a table needs to be cleared without processing a formal sale — for example, if a customer leaves without paying and the table needs to be freed for the next party. The transition is recorded in historial_estados_pedido. Returns 400 if the table has no active order.

​
Reserve a Table

PATCH /mesas/{id}/reservar (admin, mesero) Creates an order in the reservado state on the table. This marks the table as reserved without starting an active order. Returns 400 if the table is not currently disponible — you cannot reserve an occupied table. 
{"message": "Mesa reservada correctamente", "pedido_id": 43}

​
Cancel a Reservation

PATCH /mesas/{id}/cancelar-reserva (admin, mesero) Cancels the active reservation by transitioning the placeholder order to cancelado. Returns 400 if the table has no active reservation. After cancellation, GET /mesas/ will show the table as disponible.

​
Workflow Example

A typical waiter shift at table 5 follows this sequence: 
1. GET /mesas/
   → Table 5 shows estado: "disponible"

2. PATCH /mesas/5/ocupar
   → Creates empty pending order #47
   → Table 5 now shows estado: "ocupada", pedido_activo_id: 47

3. POST /pedidos/ (with id_mesa=5)
   → Adds items to the order for table 5

4. PATCH /pedidos/47/estado {"id_estado_nuevo": 2}
   → Moves to en_preparacion (kitchen picks it up)

5. PATCH /pedidos/47/estado {"id_estado_nuevo": 3}
   → Marks listo (stock is deducted automatically)

6. POST /ventas/ {"id_pedido": 47, "id_metodo_pago": 1, "monto_recibido": 100.00}
   → Order automatically moves to pagado
   → GET /mesas/ now shows table 5 as disponible
The /ocupar endpoint creates an empty order as a placeholder to immediately mark the table as occupied. The actual items are added afterward via POST /pedidos/ referencing the same id_mesa. Alternatively, you can skip /ocupar entirely and call POST /pedidos/ directly — the first order created for a table will make it appear as ocupada in GET /mesas/ all the same.

Build docs developers (and LLMs) love

Get started for freeTalk to us