Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/nelrondon/backend-proyecto-estructuras/llms.txt

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

POST /api/login verifies a user’s credentials, issues a fresh JWT, and writes it into an HTTP-only cookie valid for 7 days. It also updates the last_login timestamp in the database so you always have an accurate record of the most recent session. On success the response body includes the full user profile, allowing your client to hydrate its auth state immediately without an additional network call.

Endpoint

POST /api/login
Authentication: None required.

Request Body

username
string
required
The username registered with the account. The model performs a case-sensitive lookup: SELECT * FROM users WHERE username = ?.
password
string
required
The account password in plain text (over HTTPS). The server compares it against the stored bcrypt hash using bcrypt.compare().

Behaviour

  1. The request body is validated with Zod’s validatePartialUser (a .partial() variant of the full schema) — only username and password are required here.
  2. The model queries the database for the given username.
  3. bcrypt.compare() is called against the stored password_hash.
  4. On a successful match, last_login is updated via UPDATE users SET last_login = ? WHERE id = ?.
  5. A new 7-day JWT is signed with { id: user.id } as the payload and set as the token cookie.

Example Request

curl -c cookies.txt -s -X POST https://your-api.com/api/login \
  -H "Content-Type: application/json" \
  -d '{
    "username": "johndoe",
    "password": "secret123"
  }'

Responses

200 — Success

The token cookie is set (7-day expiry) and the response body carries the authenticated user’s profile.
id
string
The user’s UUID.
name
string
The user’s full name.
username
string
The user’s username.
email
string
The user’s email address.
phone
string
The user’s phone number.
last_login
string | Date
The timestamp of this login, set to new Date() at the moment the model runs. This value is also written back to the database.
{
  "id": "a3f8c2d1-74be-4e2a-9f61-bb0123456789",
  "name": "John Doe",
  "username": "johndoe",
  "email": "john@example.com",
  "phone": "+1-800-555-1234",
  "last_login": "2024-11-01T18:45:22.310Z"
}

422 — Validation Error

Returned when username or password is missing or fails its Zod type check.
{
  "error": "El username es requerido"
}

500 — User Not Found

Returned when no user with the given username exists in the database.
{
  "error": "Usuario no encontrado"
}

500 — Wrong Password

Returned when bcrypt.compare() returns false for the supplied password.
{
  "error": "Usuario o Contraseña incorrecta"
}
Both “user not found” and “wrong password” return HTTP 500 in the current implementation. Clients should inspect the error string to distinguish between the two cases.
After a successful login the token cookie replaces any previously stored cookie of the same name. There is no server-side session store — invalidating a token requires calling POST /api/logout or waiting for the 7-day expiry.

Build docs developers (and LLMs) love