Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ierinconc/billar-pro-backend/llms.txt

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

Every endpoint in the Billar Pro API — except POST /api/auth/login — is protected by Spring Security and requires a valid JWT bearer token. You obtain the token by calling the login endpoint, then include it in the Authorization header of every subsequent request. The server is fully stateless: no sessions are stored, and each request is independently authenticated by validating the token’s signature and expiry.

POST /api/auth/login

Authenticates a user by username and password, and returns a signed JWT token as a plain string. This endpoint is publicly accessible — no Authorization header is required.

Request body

username
string
required
The username of the account to authenticate. The default seeded account uses admin.
password
string
required
The plain-text password for the account. Spring Security compares this against the BCrypt-hashed value stored in the database. The default seeded password is billar123.

Example request

curl -X POST http://localhost:8080/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "password": "billar123"}'

Example response (HTTP 200)

The response body is a plain string — the raw JWT token, not wrapped in JSON.
eyJhbGciOiJIUzI1NiJ9...

Error responses

Both failure cases are handled by GlobalExceptionHandler and return HTTP 404 with the following JSON shape:
{
  "timestamp": "2025-01-15T10:30:00.123456",
  "status": 404,
  "error": "Recurso no encontrado",
  "mensaje": "..."
}
Conditionmensaje value
Username not found in the database"Usuario no encontrado"
Username found but password does not match"Contraseña incorrecta"

Using the token on subsequent requests

Pass the token in the Authorization header using the Bearer scheme. The JwtFilter intercepts every request (except /api/auth/login), extracts the token from this header, validates the signature and expiry, and loads the user into the security context.
curl http://localhost:8080/api/mesas \
  -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..."
Requests that arrive without a valid Authorization: Bearer <token> header are rejected by Spring Security before they reach any controller, resulting in an HTTP 401 response.

Token properties

PropertyValue
Signing algorithmHS256 (SignatureAlgorithm.HS256)
Expiration10 hours from the moment of issue (1000 × 60 × 60 × 10 ms)
Signing keyIn-memory ephemeral — generated by Keys.secretKeyFor(HS256) at application startup
Claimssub (username), iat (issued-at), exp (expiration)
The token payload (decoded) looks like this:
{
  "sub": "admin",
  "iat": 1736935800,
  "exp": 1736971800
}
The signing key is generated in memory at startup and is never persisted. Every time the server restarts, a new key is created and all previously issued tokens become invalid. Users must log in again after any server restart.

Default seeded credentials

The application seeds a default administrator account on first run:
FieldValue
usernameadmin
passwordbillar123
The password is stored as a BCrypt hash (BCryptPasswordEncoder). You can change it by updating the record in the usuarios table.

Error response schema

All unhandled RuntimeExceptions (including login failures) are caught by GlobalExceptionHandler and serialized as follows:
timestamp
string
ISO-8601 local datetime of when the error occurred (e.g. "2025-01-15T10:30:00.123456").
status
integer
The HTTP status code. For login errors this is 404.
error
string
A human-readable error category. For RuntimeException this is always "Recurso no encontrado".
mensaje
string
The specific error message from the exception (e.g. "Usuario no encontrado" or "Contraseña incorrecta").

Full error example

{
  "timestamp": "2025-01-15T10:30:00.123456",
  "status": 404,
  "error": "Recurso no encontrado",
  "mensaje": "Contraseña incorrecta"
}

Build docs developers (and LLMs) love