Authentication in Kantuta POS is built on short-lived JWT access tokens and longer-lived refresh tokens. All auth endpoints live under theDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/Eleazarguitar18/kantuta_pos_front/llms.txt
Use this file to discover all available pages before exploring further.
/auth prefix and are public — no existing token is required to call them. Once a user signs in, the access token must be sent as a Bearer header on every subsequent protected request.
TypeScript Interfaces
POST /auth/login [PUBLIC]
Signs a user in and returns a pair of JWT tokens alongside the full user object.Request body
The user’s registered email address. Must be a valid email format.
The user’s password in plain text. The API handles hashing on the backend.
Response
Short-lived JWT used to authenticate subsequent requests. Include it in the
Authorization: Bearer header.Longer-lived token used exclusively to obtain a new
access_token when the
current one expires.The full user object including their linked
persona record and assigned
role. See the Overview page for
the complete Usuario interface.SignInForm component destructures the response and persists the tokens via the loginStorage context helper:
POST /auth/refresh_token [PUBLIC]
Exchanges a validrefresh_token for a new access_token. The refresh token must be sent as the Bearer value in the Authorization header — not in the request body.
Request headers
Bearer <refresh_token> — the refresh token received at login.Response
A newly issued short-lived JWT. Store it in
localStorage and use it for all
subsequent protected requests.Axios Interceptor Pattern
Rather than manually managing token injection and 401 handling in every service call, configure a shared Axios instance with two interceptors. This is the pattern used throughout the Kantuta POS frontend.The
_retry flag on originalRequest is critical. Without it, a failed
refresh attempt would trigger the interceptor again, creating an infinite
loop before the redirect to /signin.Password Reset Flow
Resetting a password requires three sequential API calls. TheResetPasswordForm component manages the current step in local state (step: 1 | 2 | 3) and advances through each stage on success.
Request a verification code — POST /auth/reset/code
Send the user’s email address. The API dispatches a 6-character alphanumeric code to that address. The code is valid for 15 minutes.From
Request body
The email address of the account to recover.
Response
"Código de verificación enviado al correo" on success.cURL
Response
ResetPasswordForm.tsx:Verify the code — POST /auth/confirm-code
Submit the email address alongside the code the user received. A successful response confirms the code is valid and unexpired before the frontend advances to step 3.From
Request body
The same email address used in step 1.
The 6-character code from the recovery email (e.g.
"A1B2C3").Response
"Código de verificación correcto" on success.cURL
Response
ResetPasswordForm.tsx:Set the new password — POST /auth/reset-confirm
Once the code is verified, send the email and the chosen new password. On success the API updates the account’s password and the frontend redirects the user to the sign-in page after a brief delay.From
Request body
The email address of the account being recovered.
The new plain-text password. The API handles hashing server-side.
Response
"Contraseña actualizada correctamente" on success.cURL
Response
ResetPasswordForm.tsx: