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 is a multi-tenant platform — every business that registers becomes an independent tenant with its own isolated data. Clients, products, invoices, orders, employees, and every other resource belong exclusively to the company that created them. This isolation is enforced at the data layer through a company field (referencing the company _id) present on all resource documents, and at the API layer by requiring company_id as a URL path parameter on every protected route.
Company as Tenant
The Company document is the root of every tenant. When a business registers, a single Company record is created and all subsequent data is attached to it. The key fields that identify a tenant are:
| Field | Type | Description |
|---|
name_company | String | The registered business name |
nit_company | String | The business tax ID (NIT/RUT) — used as the unique tenant identifier across sub-users |
type_company | String | The industry type (e.g., farmacia, restaurante, comercial, produccion) |
counters | Map<String, Number> | Per-module bill/document counters for this tenant |
active_account | [{ name, value }] | The account activation state — an array holding one status object |
available_plans | String (enum) | The current subscription plan |
role_user | String (enum) | The principal’s role: Super Admin, Admin, Vendedor, or Sin rol |
The Super Admin role can register, manage, and view data across multiple companies. All other roles are scoped to a single tenant.
Per-Company Bill Counters
The counters field is a Map<String, Number> stored directly on the Company document. Instead of separate numbered fields, each module writes to its own named key within the map. This allows the platform to atomically increment a counter without schema changes as new modules are added.
When a company is registered with a given type_company, the corresponding counter keys are seeded from companyConfig. For example, a farmacia tenant starts with:
{
"bill_counter_pharmacy": 0,
"bill_counter_sale_pharmacy": 0,
"bill_counter_batch": 0
}
| Counter Key | Module |
|---|
bill_counter | General sales invoicing (comercial) |
bill_counter_credit | Credit notes (comercial) |
bill_counter_debit | Debit notes (comercial) |
bill_counter_shopping | Purchase orders (comercial) |
bill_counter_production | Production orders (produccion) |
bill_counter_pedido | Sublimation orders |
bill_counter_brief_case | Accounting ledger entries |
bill_counter_pedido_restaurante | Restaurant orders |
bill_counter_pharmacy | Pharmacy product records |
bill_counter_sale_pharmacy | Pharmacy sales |
bill_counter_batch | Pharmacy batch/lot records |
comercial module type would have a counters map that looks like this:
{
"bill_counter": 47,
"bill_counter_credit": 3,
"bill_counter_debit": 1
}
FAC-000048).
Sub-Users (UserCompany)
A company Admin can create multiple sub-users — employees, sellers, or consultants — who authenticate separately and operate within the same tenant. Sub-users are stored as UserCompany documents with the following key fields:
| Field | Description |
|---|
company | The _id of the parent Company document |
nit_company_by_user | The NIT/RUT of the company this user belongs to |
name_user_company | The sub-user’s display name |
email_user_company | The sub-user’s login email |
role_user_company | The sub-user’s role: Vendedor, Consultor, Diseñador, or Sin rol |
active | Boolean — whether the sub-user has been activated by the Admin |
type_dato | Always "user_company" — used by TokenAny to distinguish from a Company principal |
POST /api/user/create-user-company-by-admin/:company_id and must be explicitly activated before they can log in (see Account Activation Flow below).
Account Activation Flow
The active_account field on a Company document is an array containing a single status object. It tracks whether the Super Admin has approved the company’s payment and activated the account. The three possible states are:
value | name | Meaning |
|---|
"1" | Pendiente | The company has registered and payment is being validated by the Super Admin |
"2" | Activo | Payment was approved — the account is fully active and can access all plan features |
"3" | Inactivo | The plan period has lapsed — the account is suspended until renewed |
Pendiente. The Super Admin calls PUT /api/user/update-company/:company_id to advance the state to Activo once payment is confirmed. If the subscription expires without renewal, the state transitions to Inactivo.
For sub-users (UserCompany), the activation mechanism is simpler: a single boolean active field, toggled by the Admin via PUT /api/user/active-account-user-by-company/:user_company_id.
Data Isolation
Every API endpoint that reads or writes tenant data includes company_id as a required path parameter. Controllers use this parameter as a mandatory filter on all database queries — it is never inferred from the JWT alone. This means:
- A request to
GET /api/sublimacion/sale/list-sale/:company_id only returns sales belonging to that company_id.
- A request to
POST /api/sublimacion/sale/create-sale/:company_id/:production_id creates a sale document with company set to that company_id.
- Passing a
company_id that does not match the authenticated user’s tenant will result in an empty or unauthorized response, depending on the endpoint.
This two-layer enforcement — JWT authentication identifying the caller plus an explicit company_id scope in the URL — ensures that no cross-tenant data leakage is possible through the API.