The Ecommerce API supports two authentication strategies: JWT (JSON Web Token) as the primary method, and Google OAuth 2.0 as a social sign-in alternative. Both strategies ultimately issue a signed JWT that clients include on every protected request. Understanding which routes are public and which require a valid token is the first step to integrating with the API.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/fredy-rizo/Ecommerce/llms.txt
Use this file to discover all available pages before exploring further.
Authentication methods
JWT Authentication
Register an account, verify your email with a 5-digit code, log in, and receive a long-lived token for all subsequent requests.
Google OAuth 2.0
Sign in with an existing Google account. The API uses Passport.js to handle the OAuth flow and issues the same JWT on success.
JWT authentication flow
Regardless of which method you use to sign in, every protected endpoint expects the sametoken-access header. The full lifecycle for the native JWT path is:
Verify email
Submit the 5-digit code sent to your email to
POST /api/user/verify-account to activate the account.Passing the token
All protected endpoints are guarded by theToken middleware, which reads a custom header — not the standard Authorization header. The expected format is:
Token payload
When you decode a token issued by this API you will find the following fields:| Field | Type | Description |
|---|---|---|
id | string | MongoDB _id of the user document |
userName | string | Display name chosen at registration |
email | string | Email address |
phone | string | Phone number |
sex | string | Gender field from the user profile |
document | string | Identity document number |
documentType | string | Type of identity document |
birthdate | string | Date of birth |
roles | array | Array of role objects (see Roles) |
activate | array | Array of activation status objects |
Token expiry
Tokens are valid for 365 days from the moment they are issued. There is currently no refresh-token mechanism; after expiry the user must log in again to obtain a new token.The issued token is stored on the User document in the database. The
Token middleware verifies the signature and confirms that the corresponding user document still exists before granting access.User roles
The API uses a simple role system embedded in the token payload.| Role name | Value | Permissions |
|---|---|---|
Usuario | "1" | Standard access — browse and purchase products |
Admin | "2" | Manage products, view all users, admin operations |
Account activation status
| Status name | Value | Meaning |
|---|---|---|
Inactivo | "2" | Account created but not yet verified |
Activado | "1" | Email verified, account is active |
Activado can log in and receive a token.
Public vs. protected routes
The table below lists every authentication-related route and whether it requires a token.| Method | Endpoint | Auth required | Description |
|---|---|---|---|
POST | /api/user/register | No | Create a new inactive user account |
POST | /api/user/verify-account | No | Activate account with 5-digit code |
POST | /api/user/login | No | Log in and receive JWT |
POST | /api/user/recovery-password | No | Send password-reset code to email |
POST | /api/user/update-password | No | Reset password using the code |
GET | /auth/google | No | Initiate Google OAuth flow |
GET | /auth/google/callback | No | Google OAuth callback (handled internally) |
Error responses
TheToken middleware returns the following errors when authentication fails:
| HTTP Status | Condition | Response body |
|---|---|---|
403 | token-access header is missing | { "msj": "Sin token" } |
401 | Token signature is invalid or malformed | { "msj": "Token inexistente", "status": false } |
404 | Token is valid but the user no longer exists | { "msj": "Sin usuario" } |