CMS Users

RESTRICTED API

Requires partner / operator authorization. See CMS → Home.

CMS Users are operators — Migo or partner employees who use the backoffice to manage cardholders, cards, and partner configurations.

Application token (prerequisite)

CMS user login itself requires an application access token. Obtain it first via the application login endpoint, then send it as Authorization: Bearer <app-access-token> on the CMS user login call.

# Issue an application token
curl -X POST https://api.ali.app/cms/rest/app/auth/login \
  -H "Content-Type: application/json" \
  -d '{ "merchant": "merchant-abc123" }'

# Refresh the application token
curl -X POST https://api.ali.app/cms/rest/app/auth/refresh \
  -H "Content-Type: application/json" \
  -d '{ "refreshToken": "<app-refresh-token>" }'

See Authentication → CMS for details.

Login

curl -X POST https://api.ali.app/cms/rest/app/users/login \
  -H "Authorization: Bearer <app-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "operator@partner.com",
    "password": "*****"
  }'

Response:

{
  "success": true,
  "data": {
    "id": 1,
    "accessToken": "eyJhbGci...",
    "refreshToken": "eyJhbGci...",
    "email": "operator@partner.com",
    "name": "Operator Name"
  }
}

On subsequent CMS calls, send the returned accessToken as the x-user-token header in Bearer <accessToken> form (the gateway validates it against the CMS users service). There is no separate xUserToken value.

Refresh the token

curl -X POST https://api.ali.app/cms/rest/app/users/refresh \
  -H "Content-Type: application/json" \
  -d '{ "refreshToken": "<refresh-token>" }'

OTP flow

Some operations (grant permission, balance process requests, bulk operations) require OTP elevation. Request the OTP with POST, verify it with PUT:

# 1. Request OTP
curl -X POST https://api.ali.app/cms/rest/app/users/auth/otp \
  -H "Content-Type: application/json" \
  -d '{ "email": "operator@partner.com", "purpose": "login" }'

# 2. Verify OTP
curl -X PUT https://api.ali.app/cms/rest/app/users/auth/otp \
  -H "Content-Type: application/json" \
  -d '{ "email": "operator@partner.com", "otp": "654321", "purpose": "login" }'

There is no channel or code field; the fields are email, otp (6-digit), and purpose.

Password reset

Both password endpoints use PUT.

# Update the user's password (self-service, with reset token)
curl -X PUT https://api.ali.app/cms/rest/app/users/auth/passwords \
  -H "Content-Type: application/json" \
  -d '{
    "email": "operator@partner.com",
    "token": "<reset-token>",
    "newPassword": "NewSecureP@ss1",
    "confirmPassword": "NewSecureP@ss1"
  }'

# Generate a temporary password for a user (operator action, no body)
curl -X PUT https://api.ali.app/cms/rest/app/users/{cmsUserId}/auth/passwords \
  -H "Authorization: Bearer <token>" \
  -H "x-user-token: Bearer <cms-user-token>"

token is optional. The second endpoint generates and emails a temporary password for the target user and takes no request body.

Password requirements: min 12 chars, at least 1 upper, 1 lower, 1 digit, 1 symbol. Migo rejects the 50 most common passwords.

View user's partners and permissions

# Partners this user is assigned to
curl https://api.ali.app/cms/rest/app/users/{cmsUserId}/partners \
  -H "Authorization: Bearer <token>" \
  -H "x-user-token: Bearer <cms-user-token>"

# Permissions in a specific partner
curl https://api.ali.app/cms/rest/app/users/{cmsUserId}/partners/{partnerId}/permissions \
  -H "Authorization: Bearer <token>" \
  -H "x-user-token: Bearer <cms-user-token>"

Grant / revoke permissions

Both grant and revoke use PATCH. Permissions are referenced by numeric permissionId, and each entry requires a partnerId.

# Grant
curl -X PATCH https://api.ali.app/cms/rest/app/users/{cmsUserId}/permissions/grant \
  -H "Authorization: Bearer <token>" \
  -H "x-user-token: Bearer <cms-user-token>" \
  -H "Content-Type: application/json" \
  -d '{ "permissions": [{ "permissionId": 1, "partnerId": "partner-123" }] }'

# Revoke
curl -X PATCH https://api.ali.app/cms/rest/app/users/{cmsUserId}/permissions/revoke \
  -H "Authorization: Bearer <token>" \
  -H "x-user-token: Bearer <cms-user-token>" \
  -H "Content-Type: application/json" \
  -d '{ "permissions": [{ "permissionId": 1, "partnerId": "partner-123" }] }'

Replace a user's full permission set

To replace the entire permission set in a single call (instead of incremental grant/revoke), use PUT:

curl -X PUT https://api.ali.app/cms/rest/app/users/{cmsUserId}/permissions \
  -H "Authorization: Bearer <token>" \
  -H "x-user-token: Bearer <cms-user-token>" \
  -H "Content-Type: application/json" \
  -d '{ "permissions": [{ "permissionId": 1, "partnerId": "partner-123" }, { "permissionId": 2, "partnerId": "partner-123" }] }'

Create a CMS user

curl -X POST https://api.ali.app/cms/rest/app/partners/users \
  -H "Authorization: Bearer <token>" \
  -H "x-user-token: Bearer <cms-user-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "new-op@partner.com",
    "name": "Juan Pérez",
    "partners": ["partner-123"],
    "permissions": [1, 2, 3]
  }'

name is a single full-name field, partners is an array of partner IDs, and permissions is an array of numeric permission IDs. The new user receives an email with a temporary password and is prompted to set their own on first login.

Update a CMS user

curl -X PATCH https://api.ali.app/cms/rest/app/partners/users/{cmsUserId} \
  -H "Authorization: Bearer <token>" \
  -H "x-user-token: Bearer <cms-user-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Juan A. Pérez",
    "status": "active",
    "addPartners": ["partner-456"],
    "removePartners": ["partner-123"],
    "addPermissions": [4],
    "removePermissions": [2]
  }'

All fields are optional. Partner assignment is changed with addPartners / removePartners, and permissions with addPermissions / removePermissions.

Audit

Audit emission is not implemented in the CMS gateway/services. The documented catalog lists audit.cms_user.login, audit.permission.granted, and audit.permission.revoked.