Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/luisllatas-dev/Proyecto_Pasteleria_DonMamino/llms.txt

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

The Don Mamino API uses JSON Web Tokens (JWT) to protect write operations and sensitive data. When a user logs in, the API returns a signed token that encodes their identity, role, and branch. That token must be included in subsequent requests to protected endpoints. Public read endpoints — mainly product and location lookups — are intentionally open so that storefronts and anonymous clients can browse without signing in.

JWT token structure

After a successful login, the API returns a token whose payload contains three claims:
ClaimTypeDescription
id_usuarioINTThe authenticated user’s unique ID
rolstringThe user’s role (e.g., administrador, vendedor)
id_sedeINTThe sede (branch) the user is assigned to
Tokens expire 8 hours after they are issued. Example token payload (decoded):
{
  "id_usuario": 3,
  "rol": "vendedor",
  "id_sede": 2,
  "iat": 1747267200,
  "exp": 1747296000
}
Keep your JWT_SECRET environment variable confidential. Anyone who obtains it can forge valid tokens for any user, role, or sede. Rotate the secret immediately if it is ever exposed.

Public vs. protected endpoints

Public endpoints (no token required)

The following endpoints can be called without an Authorization header:
MethodEndpointDescription
GET/api/productosList all products
GET/api/productos/:idGet a single product
GET/api/sedesList all branches
GET/api/sedes/:idGet a single branch
GET/api/clientesList all clients
GET/api/clientes/:idGet a single client

Protected endpoints (token required)

All other operations require a valid Bearer token. This includes every write operation on products, branches, and clients, as well as all methods on orders, inventory, users, and sales reports:
MethodsEndpoints
POST, PUT, DELETE/api/productos, /api/productos/:id
POST, PUT, DELETE/api/sedes, /api/sedes/:id
POST, PUT, DELETE/api/clientes, /api/clientes/:id
GET, POST, PUT, DELETE/api/pedidos, /api/pedidos/:id
GET, POST, PUT, DELETE/api/detalles-pedido, /api/detalles-pedido/:id
GET, POST, PUT, DELETE/api/inventario, /api/inventario/:id
GET, POST, PUT, DELETE/api/usuarios, /api/usuarios/:id
GET, POST, PUT, DELETE/api/reportes-ventas, /api/reportes-ventas/:id

How to authenticate

Include the token in the Authorization header using the Bearer scheme:
curl -X POST http://localhost:3000/api/pedidos \
  -H "Authorization: Bearer <your_token>" \
  -H "Content-Type: application/json" \
  -d '{ "estado": "procesando", "id_cliente": 1, "id_usuario": 1, "id_sede": 2 }'

Token verification flow

When a protected endpoint receives a request, the middleware:
  1. Reads the Authorization header.
  2. Extracts the token from the Bearer <token> string.
  3. Verifies the token’s signature using JWT_SECRET.
  4. Attaches the decoded payload to the request so downstream handlers can read id_usuario, rol, and id_sede.

Error responses

ScenarioStatusResponse body
Authorization header is missing entirely403{ "message": "Se requiere un token de autenticación" }
Header is present but token string is missing403{ "message": "Formato de token inválido" }
Token signature is invalid or the token has expired401{ "message": "Token inválido o expirado" }
A 403 response means the request arrived with no usable token at all. A 401 response means a token was present but the server could not trust it — either it was tampered with or its 8-hour expiry has passed. Refresh your token by calling the login endpoint again.

Build docs developers (and LLMs) love