Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Carlos-Gnd/FERRED-Inventario-y-Ventas/llms.txt

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

Ferred authenticates users with JWT tokens. Send credentials to POST /api/auth/login to receive a token, then include it as a Bearer token in all subsequent requests. Tokens are stateless — the server does not maintain sessions. If the cloud database is unreachable, login automatically falls back to the local SQLite replica.

​
POST /api/auth/login

Validates an email/password pair and returns a signed JWT token together with basic user information. Endpoint: POST https://server-production-3252.up.railway.app/api/auth/login

​
Request body

​
email
string
required
The user’s email address. Normalized to lowercase before lookup.
​
password
string
required
The user’s password. Minimum 1 character.

​
Response

​
token
string
required
Signed JWT to use as a Bearer token in subsequent requests. The token encodes id, rol, sucursalId, and email.
​
usuario
object
required
Basic profile of the authenticated user.

​
Error responses

StatusCondition
400Request body fails validation (missing email, invalid format, empty password). Response: { "error": "<message>" }
401Credentials are incorrect or the account is inactive. Response: { "error": "Credenciales incorrectas" }
503Both the cloud database and the local SQLite replica are unavailable. Response: { "error": "Servicio no disponible. Intente de nuevo cuando haya conexión." }
login
curl --request POST \
  --url https://server-production-3252.up.railway.app/api/auth/login \
  --header 'Content-Type: application/json' \
  --data '{
    "email": "cajero@ferred.sv",
    "password": "mi_contrasena"
  }'

​
Usar el token

Include the token in every request to a protected endpoint using the Authorization header with the Bearer scheme.
authenticated request
curl --request GET \
  --url https://server-production-3252.up.railway.app/api/productos \
  --header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...'

​
POST /api/auth/logout

Endpoint: POST https://server-production-3252.up.railway.app/api/auth/logout Logout is handled client-side. The server returns { "ok": true } and performs no server-side token invalidation. Your client is responsible for discarding the token from storage (memory, localStorage, secure storage, etc.) so it is no longer sent in future requests.
Existing JWT tokens remain cryptographically valid until they expire. Logging out does not invalidate the token on the server. If a token is compromised, it must be allowed to expire naturally or the JWT secret rotated server-side.

​
Modo offline

When the cloud PostgreSQL database is unreachable (network error, Prisma connection timeout, or Railway outage), the login endpoint automatically retries against the local SQLite replica instead of returning an error.
  • If SQLite credentials are valid, the response is identical to a normal login response.
  • The response will include an extra header:
When login succeeds via the local replica, the server sets the response header X-Auth-Mode: offline. Check for this header if your client needs to indicate to the user that they are operating in offline mode.
The fallback is security-preserving: incorrect credentials are rejected as 401 regardless of whether the check runs against PostgreSQL or SQLite. The 503 status is only returned when both databases are unavailable.

​
Token payload

The JWT contains the following claims, which you can decode on the frontend (e.g. with jwt-decode) without making an additional request:
ClaimTypeDescription
idnumberInternal user ID
rolstringUser role: ADMIN, CAJERO, or BODEGA
sucursalIdnumber | nullBranch the user belongs to
emailstringUser email address
The nombre (display name) is returned in the login response body but is not included in the JWT payload. Store it separately after login if you need it without an additional API call.

Build docs developers (and LLMs) love

Get started for freeTalk to us