Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/edgar2420/QrPermision/llms.txt

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

User management in PermisosQR is handled through the /api/users endpoints. Super Admins have full control: they can create new accounts, update profile details and roles, reset any user’s password without needing the old one, toggle account activation status, and soft-delete accounts. Admin Operators have a single self-service capability: changing their own password via the authenticated PATCH /api/users/:id/password endpoint. All user routes require a valid JWT in the Authorization: Bearer <token> header.

First-Time Setup

Before any users exist in the database, use POST /api/auth/setup to bootstrap the first Super Admin account. This endpoint requires no authentication and is specifically designed to initialize a fresh installation.
1

Send the setup request

POST to /api/auth/setup with the initial Super Admin’s details:
{
  "name": "Admin Name",
  "email": "admin@company.com",
  "password": "secure_password",
  "role": "super_admin"
}
2

Log in with the new account

Once setup completes, use POST /api/auth/login with the same email and password to obtain a JWT token. All subsequent API calls must include this token.
POST /api/auth/setup returns an error if any user already exists in the database. It is a one-time bootstrap endpoint — use the normal POST /api/users route for all subsequent user creation.

Create a User

Route: POST /api/users — Super Admin only. All four fields are required. The service layer checks for duplicate emails and returns HTTP 409 if the address is already registered. Passwords are hashed with bcrypt (cost factor 10) before storage — the plain-text password is never persisted.
name
string
required
Full display name of the new user (max 100 characters).
email
string
required
Unique login email address. Returns 409 Conflict if already registered.
password
string
required
Plain-text password. Stored as a bcrypt hash (cost factor 10).
role
'super_admin' | 'admin_operator'
required
Role to assign. Must be exactly super_admin or admin_operator.
curl -X POST http://localhost:4000/api/users \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"name": "Ana Torres", "email": "ana@company.com", "password": "pass123", "role": "admin_operator"}'
Success response — HTTP 201:
{
  "success": true,
  "data": {
    "id": 3,
    "name": "Ana Torres",
    "email": "ana@company.com",
    "role": "admin_operator",
    "is_active": true,
    "created_at": "2024-11-01T14:22:00.000Z"
  }
}

Update a User

Route: PUT /api/users/:id — Super Admin only. You can update any combination of name, email, role, and is_active in a single request. Only the fields you include are changed — omitted fields remain untouched. Returns HTTP 400 if no valid fields are provided.
curl -X PUT http://localhost:4000/api/users/3 \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"name": "Ana Torres Quispe", "role": "super_admin"}'
To deactivate a user without deleting them, set is_active to false:
curl -X PUT http://localhost:4000/api/users/3 \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"is_active": false}'
Prefer deactivating users (is_active: false) over deleting them. Both operations prevent login, but deactivation is fully reversible — the account and all its associated permission history remain intact, which is critical for audit trails.

Change Own Password

Route: PATCH /api/users/:id/password — Any authenticated user. Operators use this to change their own password. Both the current and new password are required. The service verifies currentPassword against the stored bcrypt hash before applying the change.
curl -X PATCH http://localhost:4000/api/users/3/password \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"currentPassword": "pass123", "newPassword": "newSecure456"}'
Request body:
{
  "currentPassword": "pass123",
  "newPassword": "newSecure456"
}
Returns HTTP 400 with "Contraseña actual incorrecta" if currentPassword does not match.

Reset a User’s Password

Route: PATCH /api/users/:id/reset-password — Super Admin only. Allows a Super Admin to set a new password for any account without needing the current password. Useful when an operator is locked out. The new password must be at least 6 characters.
curl -X PATCH http://localhost:4000/api/users/3/reset-password \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"newPassword": "resetPass789"}'
Request body:
{
  "newPassword": "resetPass789"
}

Delete a User

Route: DELETE /api/users/:id — Super Admin only. Soft-deletes the user by setting is_active to false. The user record remains in the database and all permission history they created is preserved. The account can be reactivated at any time via PUT /api/users/:id with { "is_active": true }.
curl -X DELETE http://localhost:4000/api/users/3 \
  -H "Authorization: Bearer <token>"
Success response — HTTP 200:
{
  "success": true,
  "message": "Usuario desactivado"
}

List and Fetch Users

GET /api/users — Super Admin only. Returns all user accounts ordered by id ascending. Passwords (password_hash) are never included in any response.
curl http://localhost:4000/api/users \
  -H "Authorization: Bearer <token>"
GET /api/users/:id — Any authenticated user. Returns a single user record by numeric ID. Useful for profile lookups and self-inspection.
curl http://localhost:4000/api/users/2 \
  -H "Authorization: Bearer <token>"
Sample list response:
{
  "success": true,
  "data": [
    {
      "id": 1,
      "name": "Edgar Rojas Apaza",
      "email": "admin@permisosqr.com",
      "role": "super_admin",
      "is_active": true,
      "created_at": "2024-10-01T00:00:00.000Z",
      "updated_at": "2024-10-01T00:00:00.000Z"
    },
    {
      "id": 2,
      "name": "Operador Principal",
      "email": "operador@permisosqr.com",
      "role": "admin_operator",
      "is_active": true,
      "created_at": "2024-10-01T00:00:00.000Z",
      "updated_at": "2024-10-01T00:00:00.000Z"
    }
  ]
}

Build docs developers (and LLMs) love