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.

The Notifications API delivers in-app alerts to the relevant staff roles whenever a key order event occurs. Notifications are created automatically by the order controller when an order’s status changes — no manual creation is required during normal operations. Each notification targets a specific role (usuario_destino), so kitchen staff see order-ready alerts, waiters see delivery cues, and admins receive confirmation when an order is delivered. The GET /api/notifications endpoint returns only the notifications that are relevant to the currently authenticated user’s role, together with the count of unread items. Any authenticated user can read and mark their own notifications; no specific role restriction is applied.

How notifications are created

Notifications are inserted automatically by the order status-change handler (PUT /api/orders/:id/status). The routing rules are:
Order status (status value sent)DB estado_servicioNotification tipoTarget roleExample message
pendingpendienteorder_pendingcocina”Pedido #42 registrado”
preparingpreparandoorder_preparingcocina”Pedido #42 esta siendo preparado”
readylistoorder_readymesero”Pedido #42 esta listo para entregar”
deliveredentregadoorder_deliveredadmin”Pedido #42 ha sido entregado”
Notifications are stored in the notificaciones table with up to 20 most-recent entries returned per request (ordered by creado_en DESC).

Endpoints

MethodPathAuthDescription
GET/api/notificationsAny authenticatedList notifications for the current user’s role
PUT/api/notifications/:id/readAny authenticatedMark a single notification as read
PUT/api/notifications/read-allAny authenticatedMark all notifications for the current role as read

GET /api/notifications

Returns the 20 most recent notifications relevant to the authenticated user’s role, along with the count of unread items. Notifications are matched by usuario_destino = <current user's role> or usuario_destino IS NULL (broadcast).
curl -X GET https://api.example.com/api/notifications \
  -H "Authorization: Bearer <token>"
Response:
{
  "notifications": [
    {
      "id": 18,
      "tipo": "order_ready",
      "titulo": "Pedido Listo",
      "mensaje": "Pedido #42 esta listo para entregar",
      "referencia_id": 42,
      "referencia_tipo": "order",
      "leida": false,
      "creado_en": "2025-01-15T19:45:00.000Z"
    },
    {
      "id": 15,
      "tipo": "order_pending",
      "titulo": "Nuevo Pedido",
      "mensaje": "Pedido #41 registrado",
      "referencia_id": 41,
      "referencia_tipo": "order",
      "leida": true,
      "creado_en": "2025-01-15T19:30:00.000Z"
    }
  ],
  "unreadCount": 1
}
notifications
array
Array of notification objects for the authenticated user’s role. Maximum 20 items, newest first.
unreadCount
number
Total number of unread notifications for the current role. Use this to render a badge counter in the UI.

PUT /api/notifications/:id/read

Marks a single notification as read by setting leida = 1 on the specified record.
curl -X PUT https://api.example.com/api/notifications/18/read \
  -H "Authorization: Bearer <token>"
Response 200 OK:
{ "message": "Notificacion marcada como leida" }

PUT /api/notifications/read-all

Marks every unread notification targeted at the authenticated user’s role as read in one operation. Equivalent to calling PUT /api/notifications/:id/read for each unread item, but more efficient.
curl -X PUT https://api.example.com/api/notifications/read-all \
  -H "Authorization: Bearer <token>"
Response 200 OK:
{ "message": "Todas las notificaciones marcadas como leidas" }

Notifications cannot be created manually through this API. They are always generated automatically by the order status-change endpoint (PUT /api/orders/:id/status). Standard operational notifications are driven by order state transitions only.
The usuario_destino field in the database stores the role name (e.g., "cocina", "mesero", "admin\"), not a specific user ID. All users sharing the same role will see the same notification in their feed.

Build docs developers (and LLMs) love