Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/sheeplettuce/Monitor/llms.txt

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

Monitor API uses JSON Web Tokens (JWT) for authentication. Every protected endpoint requires an Authorization: Bearer <token> header. Tokens are signed with a server-side secret and carry the user’s identity and role, so no session state is stored on the server.

​
Obtaining a Token

Send a POST request to /api/auth/login with a JSON body containing username and password. On success the API returns a signed token alongside a summary of the authenticated user. 
curl -X POST http://localhost:3000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "password": "yourpassword"}'
Successful response (200 OK): 
{
  "token": "eyJhbGci...",
  "usuario": {
    "id": 1,
    "nombre": "Admin User",
    "username": "admin",
    "rol": "Administrador"
  }
}
Store the value of token — you will include it in every subsequent request to a protected endpoint.

​
Token Lifetime

Tokens are valid for 8 hours from the moment of issue. This is hardcoded in auth.service.ts: 
const token = jwt.sign(
  { id: usuario.id, username: usuario.username, rol: usuario.rol },
  process.env.JWT_SECRET!,
  { expiresIn: "8h" }
);
After 8 hours the token is rejected with a 401 response. Re-authenticate via /api/auth/login to obtain a new token.

​
Using the Token

Pass the token in the Authorization header as a Bearer credential on every request to a protected endpoint: 
curl http://localhost:3000/api/expedientes \
  -H "Authorization: Bearer eyJhbGci..."
The server middleware (verificarToken) extracts the header, verifies the JWT signature and expiry using the server’s JWT_SECRET, and attaches the decoded user payload to the request before passing it to the route handler. Requests that omit the header or present a malformed value are rejected immediately with 401.

​
Token Payload

The decoded JWT contains the following claims:
​
id
number
required
The unique numeric ID of the authenticated user in the usuario table.
​
username
string
required
The user’s login username.
​
rol
string
required
The user’s role — one of Administrador, Operador, or Tecnico. This claim drives all authorization checks across every protected route.

​
Error Responses

​
400 Bad Request
object
Returned when username or password are missing from the request body, or when the username value contains whitespace characters.
{ "error": "Usuario y contraseña requeridos" }

{ "error": "El usuario no puede contener espacios" }
​
401 Unauthorized
object
Returned when credentials are invalid (wrong password or non-existent user) or when a supplied token is expired or has an invalid signature.
{ "error": "Credenciales inválidas" }

{ "error": "Token inválido o expirado" }
​
403 Forbidden
object
Returned when the request is authenticated (valid token) but the user’s role does not meet the requirement of the endpoint being accessed. The message varies depending on which middleware rejected the request.
{ "error": "Acceso restringido a administradores" }
Returned by soloAdmin — for endpoints that require the Administrador role, such as deleting expedientes, evidence files, levantamiento records, or user accounts.
{ "error": "Acceso restringido a administradores y operadores" }
Returned by soloAdminOOperador — for endpoints that require at least the Operador role, such as creating or updating expedientes and uploading evidence files.
The /api/auth/register endpoint that creates new user accounts requires an active Administrador token in the Authorization header. Self-registration is not possible — an administrator must provision every new account.

Build docs developers (and LLMs) love

Get started for freeTalk to us