Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/FloresJesus/SS_RESTAURANT/llms.txt

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

SS Restaurant models the dining room as a set of mesas (tables), each with a live status that reflects its real-world condition. On top of that, the reservation system lets guests book a specific table in advance — or have one auto-assigned — and allows staff to convert confirmed reservations into active orders with a single API call. Conflict detection runs on every reservation write to prevent double-booking.

​
Table states

Every table carries exactly one of three states at any given moment.
StateColour in UIMeaning
libreGreenTable is clean and unoccupied; can accept a new order or reservation
ocupadaRedAn active order (status pendiente, preparando, or listo) is running on this table
mantenimientoAmberTable is out of service (cleaning, repairs, event setup); excluded from auto-assignment
The state transitions to ocupada automatically when an order is created and back to libre when an order is delivered or cancelled. Staff can also override the state manually via the quick-status panel in the Tables view.

​
Table management

Full CRUD is available under /api/tables. All routes require authentication.
MethodPathDescription
GET/api/tablesList all tables
GET/api/tables/disponiblesList only tables with estado = 'libre'
GET/api/tables/:idGet a single table
POST/api/tablesCreate a table
PUT/api/tables/:idFull update — number, capacity, and state
PATCH/api/tables/:id/estadoStatus-only update
DELETE/api/tables/:idDelete a table
Creating a table: 
POST /api/tables
Content-Type: application/json

{
  "numero": "T5",
  "capacidad": 4
}
Changing table status only: 
PATCH /api/tables/5/estado
Content-Type: application/json

{
  "estado": "mantenimiento"
}
Valid estado values: libre, ocupada, mantenimiento. Any other value returns 400.

​
Reservation workflow

1

Create a reservation

POST to /api/reservations (authenticated staff) or POST /api/public/reservations (no auth required — for online booking forms). Required fields: mesa_id, fecha_hora_inicio, fecha_hora_fin, cantidad_personas. The system runs conflict detection before inserting. Initial estado is always pendiente.
2

Confirm the reservation

When the restaurant acknowledges the booking, patch the state to confirmada:
PATCH /api/reservations/17/estado
Content-Type: application/json

{
  "estado": "confirmada"
}
3

Convert to an active order

When the guests arrive, convert the reservation to a live order. This marks the reservation completada, marks the table ocupada, and creates the pedido in a single transaction:
POST /api/reservations/17/convertir-pedido
Content-Type: application/json

{
  "mesero_id": 7,
  "observaciones": "Ocasión de cumpleaños",
  "metodo_pago": null,
  "items": [
    { "producto_id": 3, "cantidad": 2 },
    { "producto_id": 11, "cantidad": 4 }
  ]
}
The response includes the new order ID:
{
  "id": 91,
  "message": "Pedido creado correctamente desde la reservacion"
}
The reservation must be in confirmada or pendiente state. Attempting to convert a cancelada or completada reservation returns 400. This endpoint requires admin, mesero, or cajero role.

​
Public reservation endpoint

The public endpoint is mounted at /api/public/reservations and requires no authentication. It is designed for embedding on the restaurant’s website or a customer-facing booking widget. When a reservation is submitted, a cliente record is created automatically using the provided nombre and telefono. 
POST /api/public/reservations
Content-Type: application/json

{
  "nombre": "Ana Torres",
  "telefono": "77712345",
  "email": "[email protected]",
  "fecha_hora_inicio": "2025-07-20T19:00",
  "fecha_hora_fin": "2025-07-20T21:00",
  "cantidad_personas": 3,
  "mesa_id": null,
  "observaciones": "Preferimos terraza"
}
FieldRequiredNotes
nombre✅Used to create a cliente record automatically
telefono✅Used to create a cliente record automatically
fecha_hora_inicio✅ISO-like datetime string YYYY-MM-DDTHH:mm
fecha_hora_fin✅ISO-like datetime string YYYY-MM-DDTHH:mm
cantidad_personas✅Minimum seating required
mesa_idOptionalIf omitted, the system auto-assigns the smallest available table with sufficient capacity
emailOptionalStored on the customer record
observacionesOptionalNotes passed to the reservation
If mesa_id is omitted and no suitable table is free in the requested window, the API responds with 400 No hay mesas disponibles en ese horario.

​
Conflict detection

checkTableAvailability runs before every reservation insert or update. It queries for overlapping active reservations: 
estado IN ('pendiente', 'confirmada')
AND :fecha_hora_inicio < r.fecha_hora_fin
AND :fecha_hora_fin > r.fecha_hora_inicio
A conflict returns 409 La mesa ya esta reservada en ese horario. When updating an existing reservation the current reservation’s ID is excluded from the conflict check.

​
Querying available tables

Use GET /api/reservations/mesas-disponibles to get a list of tables that are free for a given time window and have enough capacity. All three parameters are mandatory. 
GET /api/reservations/mesas-disponibles
  ?fecha_hora_inicio=2025-07-20T19:00
  &fecha_hora_fin=2025-07-20T21:00
  &cantidad_personas=3
Response: 
[
  { "id": 2, "numero": 2, "capacidad": 4 },
  { "id": 7, "numero": 7, "capacidad": 6 }
]
Tables with estado = 'mantenimiento' are excluded from results.

​
Reservation states

StateDescription
pendienteCreated but not yet acknowledged by staff
confirmadaStaff has confirmed the booking
canceladaCancelled by staff or guest; releases the table if no active orders exist
completadaConverted to an order or manually closed
no_asistioAuto-assigned by a scheduled check when fecha_hora_fin passes without the reservation being converted
The GET /api/reservations endpoint automatically calls markExpiredNoShow before returning results, so any reservation whose end-time has passed while still pendiente or confirmada is silently transitioned to no_asistio before the response is sent.
Cancelling a reservation only releases the table to libre if there are no active orders (in pendiente, preparando, or listo state) still running on that table. If active orders exist, the table state is left unchanged.

Build docs developers (and LLMs) love

Get started for freeTalk to us