Skip to main content
A module (Modulo) represents a discrete section or feature of your application. Modules are the targets of permission grants — you don’t assign permissions to abstract roles, you assign them to specific modules. Every protected endpoint in WebCorporativa maps to exactly one module.

​
Module model

FieldTypeConstraintsDescription
IdModulointPrimary key, auto-generatedUnique module identifier
strNombreModulostringRequired, max 100 charsHuman-readable display name
RutastringRequired, max 50 charsFrontend route for this module (e.g. /Module/Usuario)
ClavestringRequired, max 50 chars, uniqueShort key used as the prefix in permission strings
public class ModuloModel
{
    [Key]
    public int IdModulo { get; set; }
    [Required, MaxLength(100)]
    public string strNombreModulo { get; set; }
    [Required, MaxLength(50)]
    public string Ruta { get; set; }
    [Required, MaxLength(50)]
    public string Clave { get; set; }
    public ICollection<PermisosPerfilModel> PermisosPerfilModels { get; set; }
}

​
The Clave field

Clave is the unique identifier that links a module to its permission strings. When the API constructs or checks a permission, it uses the module’s Clave as the prefix: 
{Clave}.{action}
For example, a module with Clave = "usuario" produces the following permission strings:
Permission stringAction
usuario.agregarCreate a user
usuario.editarEdit a user
usuario.eliminarDelete a user
usuario.consultarList or search users
usuario.detalleRetrieve a single user
Clave must be unique across all modules. The API rejects requests to create or update a module if the provided Clave already exists in the system. Choose short, lowercase, alphanumeric keys without spaces.

​
The Ruta field

Ruta stores the frontend route that maps to this module (for example, /Module/Usuario). The API returns this value in the GET /api/Menu response so your client can build navigation links without hard-coding routes.
Keep Ruta values consistent with your frontend routing conventions. The API treats Ruta as an opaque string — it does not validate or resolve it.

​
Built-in seeded modules

The following modules are seeded automatically on first startup. Their Clave values are used throughout the permission system:
Display nameRutaClave
Modulos/Module/Modulosmodulo
Perfil/Module/Perfilperfil
PermisosPerfil/Module/PermisosPerfilpermisosperfil
Usuario/Module/Usuariousuario
Principal 1.1/Principales/PrincipalU1principal11
Principal 1.2/Principales/PrincipalU2principal12
Principal 2.1/Principales/PrincipalD1principal21
Principal 2.2/Principales/PrincipalD2principal22
These modules are registered at application startup. If you delete a seeded module, its permission grants for all profiles are also removed. Endpoints that enforce those permissions will return 403 Forbidden for all non-administrator users.

​
Adding custom modules

You can register additional modules through the /api/Modulo endpoints. Once a module is created, you can grant permissions for it to any profile via POST /api/PermisosPerfil. The module’s Clave becomes the prefix for all permission strings associated with it. 
{
  "strNombreModulo": "Reportes",
  "Ruta": "/Module/Reportes",
  "Clave": "reportes"
}
This produces permission strings like reportes.agregar, reportes.consultar, and so on.

​
Managing modules

List modules

Retrieve all registered modules.

Create a module

Register a new module with a unique Clave.

Update a module

Update a module’s name, route, or key.

Delete a module

Remove a module and all associated permission grants.

Profiles

How profiles collect module permissions and assign them to users.

Permissions

The full permission string reference and how enforcement works.

Dynamic menu

How the API uses modules to build the authenticated user’s navigation menu.

Build docs developers (and LLMs) love

Get started for freeTalk to us