Modules & Actions
Full RBAC model with module-level permission matrices.
The Full authorization model organizes permissions into modules — discrete functional areas of your application — with actions assigned per module per role.
How modules work
A module represents a bounded area of your app (e.g., BOOKINGS, PROPERTIES, INVOICES). Each module defines the actions that are meaningful within it. Roles are then granted specific actions on specific modules.
Role: Property Manager
├── PROPERTIES → [READ, CREATE, UPDATE, DELETE]
├── BOOKINGS → [READ, LIST]
└── INVOICES → [READ]
Registering modules
Modules are registered by your application via the API. Registration is synchronous: the module is stored before the response returns (see the Modules API).
curl -X POST https://api.platformxe.com/api/v1/permissions/modules \
-H "Content-Type: application/json" \
-H "x-api-key: pxk_live_your_api_key_here" \
-d '{
"id": "bookings",
"app": "lettings",
"name": "Bookings",
"description": "Booking management",
"paths": ["bookings", "bookings/approve"]
}'
await px.permissions.registerModule({
id: 'bookings',
app: 'lettings',
name: 'Bookings',
description: 'Booking management',
paths: ['bookings', 'bookings/approve'],
});
Which paths a module grants
A module permission grants a checked path only when the path is the module id or sits under it, compared case-insensitively on the module id:
| Module id | Path | Granted |
|---|---|---|
book | book | Yes |
book | book/list | Yes |
book | bookkeeping/ledger | No |
book | bookings | No |
Before 2026-09-15 a module matched any path that merely started with its id, so book also granted bookkeeping/.... If you relied on that, grant the other module explicitly.
Module limits by plan
| Plan | Max modules |
|---|---|
| Free | 5 |
| Basic | 20 |
| Pro | 50 |
| Enterprise | Unlimited |
Assigning module permissions to a role
curl -X PUT https://api.platformxe.com/api/v1/permissions/roles/role_abc123/modules \
-H "Content-Type: application/json" \
-H "x-api-key: pxk_live_your_api_key_here" \
-d '{
"modules": [
{ "moduleId": "mod_bookings", "actions": ["READ", "CREATE", "UPDATE"] },
{ "moduleId": "mod_properties", "actions": ["READ", "LIST"] }
]
}'
await px.permissions.setModulePermissions('role_abc123', {
modules: [
{ moduleId: 'mod_bookings', actions: ['READ', 'CREATE', 'UPDATE'] },
{ moduleId: 'mod_properties', actions: ['READ', 'LIST'] },
],
});
Federated keys
When modules are shared across apps via Federation, they use a prefixed key format: PREFIX:MODULE. For example, if an app with prefix LT registers a BOOKINGS module, it becomes LT:BOOKINGS in the federation namespace.
Module actions are distinct from the six Vault-aligned actions used in Simple capabilities. Modules can define any action strings meaningful to your domain (e.g., APPROVE, ARCHIVE, PUBLISH).