Permissions (RBAC)

Migo uses role-based access control (RBAC). Users hold roles, roles hold permissions, and every endpoint declares which permission(s) it requires.

Core concepts

• Permission — a granular capability expressed as an { action, resource } pair (e.g. action checkCvv on resource cards, action transferBetweenCards on resource cards). Permissions are identified internally by a numeric permissionId.
• Role — a named bundle of permissions (e.g. admin, support). A role's permissions are referenced by their numeric IDs.
• User — a person (cardholder or CMS operator) with one or more roles assigned, plus optional directly-granted permissions.

Wallet Gateway endpoints (end-users)

List all permissions

curl https://api.ali.app/rest/users/permissions \
  -H "Authorization: Bearer <token>"

Create permissions (batch)

Rarely used — permissions come from Migo's definitions. The endpoint creates one or more permissions, each described by { resource, action, description? }:

curl -X POST https://api.ali.app/rest/users/permissions \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "permissions": [
      { "resource": "cards", "action": "checkCvv", "description": "Request a CVV view token" }
    ]
  }'

Grant / revoke permissions on a user

Both grant and revoke use the same { permissions: [...] } shape, where each entry is { roleId, permissionId, granted }. Set granted: true to grant and granted: false to revoke:

# Create / grant direct user permissions
curl -X POST https://api.ali.app/rest/users/{id}/permissions \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{ "permissions": [ { "roleId": 1, "permissionId": 10, "granted": true } ] }'

# Update (grant/revoke) direct user permissions
curl -X PATCH https://api.ali.app/rest/users/{id}/permissions \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{ "permissions": [ { "roleId": 1, "permissionId": 10, "granted": false } ] }'

Roles (Wallet Gateway)

List roles

curl https://api.ali.app/rest/users/roles \
  -H "Authorization: Bearer <token>"

Create roles (batch)

The body is { roles: [...] }. Each role has a name, a permissions array of numeric permission IDs, and an optional description:

curl -X POST https://api.ali.app/rest/users/roles \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "roles": [
      { "name": "branch_manager", "permissions": [1, 2, 3], "description": "Branch operations" }
    ]
  }'

Update a role

Updates are expressed as add/remove sets of numeric permission IDs (there is no full-replace permissions field):

curl -X PATCH https://api.ali.app/rest/users/roles/{name} \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{ "addPermissions": [4, 5], "removePermissions": [1], "description": "Updated role" }'

Role's permissions

curl https://api.ali.app/rest/users/roles/{name}/permissions \
  -H "Authorization: Bearer <token>"

Assign / unassign roles on a user

Role assignment is a PATCH with add/remove sets of role names (there is no POST /users/{id}/roles):

curl -X PATCH https://api.ali.app/rest/users/{id}/roles \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{ "addRoles": ["branch_manager"], "removeRoles": [] }'

CMS endpoints (operators)

Same model, different endpoints — see CMS → Permissions & roles.

Standard permissions

Permissions are { action, resource } pairs (camelCase actions), not dotted strings. A non-exhaustive sample drawn from the gateway permission map:

Resource	Action	Grants
cards	createCard	Issue a new card
cards	checkCard	Look up / verify a card
cards	checkCvv	Request a CVV view token
cards	cardActivation	Activate a card
cards	assignPIN	Set / change a card PIN
cards	updateStatus	Block / unblock (status change)
cards	transferBetweenCards	Execute card-to-card transfers
cards	getAllByUser	List a user's cards
users	createPermission	Create permissions in the catalog
users	createRole / updateRole	Manage roles
users	updateAuthUserRoles	Assign / unassign user roles
users	createAuthUserPermissions / updateAuthUserPermissions	Grant / revoke direct user permissions
leads	create / update / fileUpload	Onboarding lead lifecycle
businesses	createBusiness / createBranch / updateTerminal	Manage businesses
reports	payfacConciliation	PayFac conciliation report
webhooks	volcanWebhook	Card-processor inbound webhook

The full, authoritative list lives in the gateway permission map (PermissionsMap); coordinate with Migo before relying on a specific pair.

Effective permissions

A user's effective permission set is the union of all role permissions plus directly-granted permissions.

Check via:

curl https://api.ali.app/rest/users/{id}/permissions \
  -H "Authorization: Bearer <token>"