Saltar al contenido principal
Migo Docs

Permisos y Roles

API RESTRINGIDA

Requiere autorización de partner / operador. Consulta CMS → Inicio.

El lado CMS del RBAC. Mismo modelo que el Wallet Gateway, pero con endpoints y alcance distintos. Los permisos se modelan como pares resource + action (no como cadenas con puntos).

Listar módulos del CMS

No existe un GET /app/permissions. Para leer los módulos disponibles del CMS (cada uno con sus permisos), usa:

curl https://api.ali.app/cms/rest/app/modules \
-H "Authorization: Bearer <token>" \
-H "x-user-token: Bearer <cms-user-token>"

Los permisos efectivos de un usuario se leen por usuario/partner mediante GET /app/users/{cmsUserId}/partners/{partnerId}/permissions (consulta Usuarios CMS).

Permisos estándar del CMS

Una selección de los pares resource / action integrados:

RecursoAcciones
userscreate, update, list, detail, change_status
bulk-createcreate
cardholderscreate, update, list, detail, otp
cards-adminactivate, block, unblock, transfer, addFunds, withdrawFunds, detail, otp, balance-account
card-movementslist, detail, revert
balance-managementcreate, list, cancel, otp
approvalslist, detail, update

Crear un permiso

El cuerpo es un arreglo de elementos { resource, action, description? }:

curl -X POST https://api.ali.app/cms/rest/app/permissions \
-H "Authorization: Bearer <token>" \
-H "x-user-token: Bearer <cms-user-token>" \
-H "Content-Type: application/json" \
-d '{
"permissions": [
{ "resource": "finance", "action": "export", "description": "Export monthly finance reports" }
]
}'

Los permisos personalizados deben definirse en el código base de Migo para que se apliquen — créalos únicamente en coordinación con tu account manager de Migo.

Asignar permisos a usuarios CMS

Usa los endpoints de Usuarios CMS.

Alcance: por partner

Cada entrada de otorgar/revocar requiere un partnerId — cada par { permissionId, partnerId } acota el permiso al partner indicado. El DTO no tiene una forma opcional/global, por lo que no existe un modo de "omitir partnerId para alcance global".

Buenas prácticas

  • Usa roles en lugar de otorgamientos directos de permisos para cualquier cosa que se aplique a más de 5 usuarios.
  • Revisa los otorgamientos trimestralmente.

Auditoría

El catálogo de eventos de webhook lista audit.permission.granted y audit.permission.revoked. La emisión de auditoría no está implementada en el gateway/servicios del CMS auditados aquí; confirma el payload exacto con Migo antes de depender de él.