TuKit provides two distinct authentication strategies for clients of the sporting designs marketplace API. The first is a classic email/password flow backed by JSON Web Tokens (JWT), which requires users to verify their account via a 5-digit emailed code before they can log in. The second is a Google OAuth 2.0 flow implemented with Passport.js, which lets users sign in with an existing Google account — creating a new User document automatically if none exists. Both strategies ultimately result in the user possessing a JWT that can be used to access protected resources, but they follow separate code paths and session mechanisms.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/fredy-rizo/tukit/llms.txt
Use this file to discover all available pages before exploring further.
JWT Authentication
Register with email and password, verify your account with a 5-digit code,
and log in to receive a signed JWT valid for 365 days.
Google OAuth 2.0
Sign in with your Google account via Passport.js. New users are created
automatically; returning users are looked up by their Google ID.
User Activation Flow
Every email/password account must pass through an activation step before login is permitted. The sequence is:Register
The client POSTs to
/api/user/register with userName, email, and password. The API creates the user record with activate set to [{name: "Inactivo", value: "2"}] and generates a random 5-digit numeric code stored in the login_code field.Receive Verification Code
The 5-digit code is immediately dispatched to the user’s email address via Nodemailer (Gmail transport). The email includes the code prominently so the user can copy it.
Verify Account
The client POSTs the email address and the received code to
/api/user/verify-account. If the code matches login_code, the API copies the code into login_code_confirmed and updates activate to [{name: "Activado", value: "1"}].Role System
User roles are stored as an array of{name, value} objects on the User document. TuKit defines two roles:
| Role name | Value | Description |
|---|---|---|
Usuario | "1" | Standard registered user — the default assigned on registration. |
admin | "2" | Administrator — can manage other users’ roles and access admin-only endpoints. |
POST /api/user/update-role/:userId/:adminId. The API verifies that the requesting adminId belongs to a user whose roles array contains {name: "admin", value: "2"} before applying the change.
Activate Field
Theactivate field mirrors the role structure — an array of {name, value} objects — and controls whether a user may log in:
| Name | Value | Meaning |
|---|---|---|
Activado | "1" | Account is active; the user has successfully verified their email. |
Inactivo | "2" | Account is pending verification; login is blocked. |
activate: [{name: "Activado", value: "1"}] immediately, since Google has already verified the email address.
All protected endpoints require the JWT to be passed in the
token-access request header. This is a custom header — it is not the standard Authorization: Bearer <token> pattern used by many other APIs.