The Sessions API records every completed training session for the authenticated user. Each session captures which routine was performed, the date it occurred, and the exact sets and reps logged for every exercise — down toDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/Blackterz2/Proyecto_5to_Semestre/llms.txt
Use this file to discover all available pages before exploring further.
peso, repeticiones, and completada per set. All write operations use atomic SQL transactions so session data is always consistent.
All endpoints require a valid JWT in the
Authorization: Bearer <token> header. The usuario_id is extracted exclusively from the token payload — any usuario_id sent in the request body is overwritten before it reaches the database. This prevents ID spoofing.GET /api/sesiones
GET/api/sesiones
Returns the full training history for the authenticated user, ordered by fecha DESC then id DESC so the most recent session always appears first. Each item includes aggregate stats (volumen_total_kg, total_series) computed directly in SQL.
Auth required: Yes — Authorization: Bearer <token>
Responses
200 OK — History retrieved
200 OK — History retrieved
401 Unauthorized — Missing or invalid token
401 Unauthorized — Missing or invalid token
Example
POST /api/sesiones
POST/api/sesiones
Logs a complete training session. The request must include the routine used, the date, and a nested structure of exercises with their individual sets. All three INSERT statements (into sesiones_entrenamiento, sesion_ejercicios, and sesion_series) execute inside a single SQL transaction — if any step fails, the entire session is rolled back.
Auth required: Yes — Authorization: Bearer <token>
The SQL transaction guarantees atomicity: either all three layers of data (session header, exercise entries, and individual series) are committed together, or none of them are. A server crash mid-write will never leave orphaned rows in
sesion_ejercicios or sesion_series.Request body
ID of the routine performed during this session. Must reference an existing routine.
Date of the training session in
YYYY-MM-DD format (e.g., "2025-01-15").Optional free-text notes about the session (e.g.,
"Felt strong today").Optional total session duration in minutes.
Array of exercise entries. Must contain at least one item. Each item must include an
ejercicio_id and at least one set in series.Responses
201 Created — Session logged
201 Created — Session logged
400 Bad Request — Validation failures
400 Bad Request — Validation failures
400 Bad Request — Foreign key violation
400 Bad Request — Foreign key violation
Example
GET /api/sesiones/ultima/:rutina_id
GET/api/sesiones/ultima/:rutina_id
Retrieves the most recent training session the authenticated user has completed for a specific routine, with series data grouped by exercise. This endpoint powers the progressive overload feature: the frontend reads previous weights and reps and pre-fills the next session’s input fields as a reference target.
Auth required: Yes — Authorization: Bearer <token>
Path parameters
Numeric ID of the routine to look up the last session for.
Responses
200 OK — No previous sessions for this routine
200 OK — No previous sessions for this routine
When no sessions exist, the server returns
200 with a null data payload rather than 404, so the frontend can distinguish “never trained” from “session not found”.400 Bad Request — Non-numeric rutina_id
400 Bad Request — Non-numeric rutina_id
Example
GET /api/sesiones/:id
GET/api/sesiones/:id
Returns the complete detail of a single training session, including every exercise and every set logged within it. The query joins sesiones_entrenamiento, sesion_ejercicios, ejercicios, and sesion_series, then restructures the flat tabular result into a nested JSON object.
Auth required: Yes — Authorization: Bearer <token>
Path parameters
Numeric ID of the session to retrieve.
Responses
400 Bad Request — Non-numeric ID
400 Bad Request — Non-numeric ID
404 Not Found — Session not found or belongs to another user
404 Not Found — Session not found or belongs to another user
The server returns
404 in both cases — it does not reveal whether the session exists but belongs to another user.