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:
| Claim | Type | Description |
|---|
id_usuario | INT | The authenticated user’s unique ID |
rol | string | The user’s role (e.g., administrador, vendedor) |
id_sede | INT | The 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:
| Method | Endpoint | Description |
|---|
| GET | /api/productos | List all products |
| GET | /api/productos/:id | Get a single product |
| GET | /api/sedes | List all branches |
| GET | /api/sedes/:id | Get a single branch |
| GET | /api/clientes | List all clients |
| GET | /api/clientes/:id | Get 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:
| Methods | Endpoints |
|---|
| 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:
- Reads the
Authorization header.
- Extracts the token from the
Bearer <token> string.
- Verifies the token’s signature using
JWT_SECRET.
- Attaches the decoded payload to the request so downstream handlers can read
id_usuario, rol, and id_sede.
Error responses
| Scenario | Status | Response body |
|---|
Authorization header is missing entirely | 403 | { "message": "Se requiere un token de autenticación" } |
| Header is present but token string is missing | 403 | { "message": "Formato de token inválido" } |
| Token signature is invalid or the token has expired | 401 | { "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.