TheDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/devdavco/backend_1/llms.txt
Use this file to discover all available pages before exploring further.
PUT /reserva/update/{id} endpoint is a deliberately scoped mutation: it changes only the estado field of an existing reservation. Time windows (horaInicio, horaFinUsuario, horaFinTotal), participant IDs (usuarioId, espacioId), and the version counter are all managed by the server and cannot be overridden through this endpoint. The response returns the complete, updated Reserva object reflecting the new status and the incremented version.
Path parameters
The integer primary key of the reservation to update. Must reference an existing record in the
reservas table.Request body
The reservation ID as carried in the
UpdateReservaRequest DTO. The service resolves the target record using the path parameter {id}, not this field — but including it keeps the DTO consistent. Both values should reference the same reservation.The new status for the reservation. Must be one of
confirmada, pendiente, or cancelada.Request
Response
Returns200 OK with the full updated UpdateReservaResponse object.
Response fields
The reservation’s primary key, unchanged from creation.
ID of the user who owns the booking. Not modified by this endpoint.
ID of the reserved coworking space. Not modified by this endpoint.
Original start time in
yyyy-MM-dd HH:mm format. Not modified by this endpoint.Original user session end time in
yyyy-MM-dd HH:mm format. Not modified by this endpoint.Original absolute end time (including cleaning buffer) in
yyyy-MM-dd HH:mm format. Not modified by this endpoint.The newly applied status. One of
confirmada, pendiente, or cancelada.Optimistic-locking counter. JPA’s
@Version mechanism increments this value automatically every time the record is saved. After a successful update this will be one higher than the value returned by the previous read.Because the
Reserva entity uses JPA’s @Version annotation for optimistic locking, the version field in the response will always be incremented by 1 compared to the value present before the update. If two concurrent requests attempt to update the same reservation, the second will encounter an OptimisticLockException and fail.