Documentation Index
Fetch the complete documentation index at: https://mintlify.com/azahel79/Spartans-gym/llms.txt
Use this file to discover all available pages before exploring further.
Staff user accounts control who can log into Spartans Gym and what they can do once inside. The User model is entirely separate from the Client model — clients are gym members tracked for attendance and memberships, while users are the staff members who operate the system. All user management endpoints require an authenticated admin session; receptionists have no access to this area.
The database is seeded with an initial admin account using the SEED_ADMIN_EMAIL and SEED_ADMIN_PASSWORD environment variables. Change this password immediately after your first login. Anyone who knows the seed credentials and can reach your API has full admin access.
User Model
| Field | Type | Description |
|---|
id | Int (auto-increment) | Primary key |
email | String (unique) | Login email address |
password | String | bcrypt hash — never stored in plaintext |
role | Role enum | admin or recepcionista (default: recepcionista) |
createdAt | DateTime | Timestamp of account creation |
updatedAt | DateTime | Timestamp of last modification |
Password Security
Passwords are hashed with bcrypt at a salt cost of 10 rounds before being written to the database. The raw password is never stored or logged anywhere in the system.
// password.service.ts
const SALT_ROUNDS = 10;
export async function hashPassword(password: string): Promise<string> {
return bcrypt.hash(password, SALT_ROUNDS);
}
export async function verifyPassword(password: string, hash: string): Promise<boolean> {
return bcrypt.compare(password, hash);
}
API Endpoints
All /api/users routes require a valid JWT Bearer token belonging to an admin user. Requests from receptionists receive 403 Forbidden.
List All Users
Returns every user account ordered by creation date (newest first). The response omits password hashes.
curl -X GET https://YOUR_API/api/users \
-H "Authorization: Bearer TOKEN"
{
"success": true,
"data": [
{
"id": 1,
"email": "admin@spartansgym.com",
"role": "admin",
"createdAt": "2024-01-15T10:00:00.000Z"
},
{
"id": 2,
"email": "staff@gym.com",
"role": "recepcionista",
"createdAt": "2024-03-01T09:30:00.000Z"
}
]
}
Create a User
Creates a new staff account. If role is omitted, it defaults to recepcionista. The email must be unique across all users.
# Create a receptionist (default role)
curl -X POST https://YOUR_API/api/users \
-H "Authorization: Bearer TOKEN" \
-H "Content-Type: application/json" \
-d '{"email":"staff@gym.com","password":"secure123!","role":"recepcionista"}'
email, password
Optional fields: role (defaults to recepcionista)
Response 201 Created:
{
"success": true,
"data": {
"id": 3,
"email": "staff@gym.com",
"role": "recepcionista",
"createdAt": "2024-06-20T14:22:00.000Z"
}
}
400 Bad Request with "error": "Ya existe un usuario con ese email".
Change a User’s Role
Toggles a user between admin and recepcionista. The only accepted values for the role field are "admin" and "recepcionista".
# Promote user 2 to admin
curl -X PATCH https://YOUR_API/api/users/2/role \
-H "Authorization: Bearer TOKEN" \
-H "Content-Type: application/json" \
-d '{"role":"admin"}'
# Demote user 2 back to recepcionista
curl -X PATCH https://YOUR_API/api/users/2/role \
-H "Authorization: Bearer TOKEN" \
-H "Content-Type: application/json" \
-d '{"role":"recepcionista"}'
{
"success": true,
"data": {
"id": 2,
"email": "staff@gym.com",
"role": "admin",
"createdAt": "2024-03-01T09:30:00.000Z"
}
}
Delete a User
Permanently removes the user record from the database. This action cannot be undone.
curl -X DELETE https://YOUR_API/api/users/2 \
-H "Authorization: Bearer TOKEN"
{
"success": true,
"message": "Usuario eliminado correctamente"
}
404 Not Found.
You cannot delete your own account. The frontend checks whether the target user’s email matches your active session and blocks the request before it is sent, showing a warning toast instead.
Managing Users in the UI
User management is available inside the Config page under the Roles y Permisos tab. The tab is visible only to admins.
Open Config
Navigate to /config in the sidebar. Only admin accounts can access this page.
Select Roles y Permisos
Click the Roles y Permisos tab in the left navigation panel to see the full list of staff accounts.
Manage existing users
Each user card shows their email, ID, creation date, and current role badge. Use the swap icon to toggle their role between admin and recepcionista, or the trash icon to permanently delete the account. Both controls are hidden when the card represents your own account.
Create a new user
Scroll to the Agregar Nuevo Usuario form at the bottom of the tab. Enter the email, password, and desired role, then click Crear Usuario. The new account appears in the list immediately.
Seeded Admin Account
On first deployment the database seed script creates one admin account using environment variables:
| Variable | Purpose |
|---|
SEED_ADMIN_EMAIL | Email address for the initial admin account |
SEED_ADMIN_PASSWORD | Plaintext password (hashed by the seed script before storage) |
Treat your SEED_ADMIN_PASSWORD environment variable like a private key. Keep it out of version control and rotate it after the initial setup is complete.