Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/fredy-rizo/MultiSas/llms.txt

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

MultiSas recognises two types of authenticated principals: the Company (the tenant owner, registered by the Super Admin) and the UserCompany (sub-users created by a company’s Admin to represent employees, sellers, or consultants). Both principals authenticate using JWTs delivered in the token-access header, but they carry different role fields and are stored in separate MongoDB collections. Every protected route enforces the caller’s role through the TokenAuthorize middleware, which runs after the token has been validated and req.user has been populated.

​
Company Roles

The role_user field on the Company document is an enum with four possible values:
RoleDescription
Super AdminPlatform-level administrator. Registers companies, assigns and manages subscription plans, and has read/write access across all tenants. There is typically one Super Admin for the entire MultiSas deployment.
AdminCompany administrator. Manages all resources within their own company — products, clients, invoices, employees — and creates and activates sub-users (UserCompany).
VendedorSeller role. Scoped to sales and client-facing operations within the company. Cannot manage other users or plan settings.
Sin rolDefault value assigned on registration. A company with this role has no functional permissions until the Super Admin explicitly assigns a role.

​
UserCompany Roles

Sub-users have their own role field — role_user_company — with a separate enum defined on the UserCompany model:
RoleDescription
VendedorSeller — can perform sales and client lookups within the parent company
ConsultorConsultant — typically read-oriented access for reporting or analysis
DiseñadorDesigner — access to template and presentation-layer features
Sin rolDefault — no permissions until the Admin assigns a role
Sub-users are created by a company Admin (or Super Admin) via: 
POST /api/user/create-user-company-by-admin/:company_id
The nit_company_by_user field on the UserCompany document mirrors the parent company’s nit_company, providing a secondary linkage by tax ID in addition to the company foreign key (which holds the parent’s _id).

​
How Role Enforcement Works

The TokenAuthorize(...roles) middleware accepts a variadic list of allowed roles and returns a handler that checks the authenticated principal’s role against that list. It handles both Company and UserCompany principals transparently by inspecting req.user.type_dato: 
// Only Admin and Super Admin can create an employee record
router.post(
  '/create/:company_id',
  TokenAny,
  TokenAuthorize('Admin', 'Super Admin'),
  create_employee
);
Internally, TokenAuthorize performs the following checks in order:
  1. Principal lookup — re-fetches the Company or UserCompany document from the database to ensure the role has not changed since the JWT was issued.
  2. Role check — verifies that role_user (or role_user_company) is included in the roles array passed to the middleware.
  3. Active check (UserCompany only) — verifies that data_user.active === true before allowing the request through.
The possible rejection responses are:
ConditionHTTP StatusResponse body
Role not in allowed list403{"msj": "No tienes permisos", "status": false}
UserCompany active === false403{"msj": "Usuario inactivo", "status": false}
Company document not found404{"msj": "Empresa no encontrada", "status": false}
UserCompany document not found404{"msj": "Usuario de empresa no encontrado", "status": false}

​
Account Activation

A newly created UserCompany document has active: false by default. Until an Admin explicitly activates the sub-user, TokenAuthorize will reject every request from that account with {"msj": "Usuario inactivo", "status": false}. Activation is performed by the company Admin (or Super Admin): 
PUT /api/user/active-account-user-by-company/:user_company_id
This toggles the active boolean on the UserCompany document. The same endpoint can be used to deactivate a sub-user if their access should be revoked — the active field is set back to false and all subsequent requests from that JWT are rejected.

​
TokenAny vs Token vs TokenUserCompany

MultiSas exposes three token-validation middlewares. Each one determines which type of JWT is accepted and what gets written to req.user.Token Accepts only a Company JWT. Looks up the caller in the Company collection. Use this on routes that should never be accessible to sub-users, such as internal Super Admin management endpoints.
// Only Company principals (Admin / Super Admin) can reach this handler
router.put('/update-company/:company_id', Token, TokenAuthorize('Super Admin'), update_data_company);
TokenUserCompany Accepts only a UserCompany JWT. Looks up the caller in the UserCompany collection. Use this on routes that are exclusively for sub-users and should reject Company-level tokens.
// Only sub-users can reach this handler
router.get('/my-tasks', TokenUserCompany, get_my_tasks);
TokenAny Accepts either a Company JWT or a UserCompany JWT. It tries the Company collection first; if no match is found, it tries UserCompany. The resolved principal type is stored in req.user.type_dato ("company" or "user_company"), which TokenAuthorize uses to apply the correct role check. This is the most flexible option and is the standard choice for any endpoint that both Admins and sub-users should be able to call.
// Both Admins and Vendedores can list sales
router.get('/list-sale/:company_id', TokenAny, TokenAuthorize('Admin', 'Vendedor', 'Super Admin'), list_sale);
Prefer TokenAny combined with TokenAuthorize for all business-logic routes. This pattern future-proofs your routes against new sub-user role types and avoids the need to maintain separate route definitions for Company and UserCompany callers. Reserve Token only for routes that must be strictly inaccessible to sub-users by design.

Build docs developers (and LLMs) love

Get started for freeTalk to us