Team and roles
Your Boundless dashboard supports multiple users per merchant account, each with roles that control which areas they can see and act on. Grant each person the lowest role that covers their job.
Roles
| Role | Meant for | Dashboard areas |
|---|---|---|
| ADMIN | Account owners and managers | Everything below, plus the configuration areas only administrators see: MID configuration, acquirer routes, API keys, webhooks, iframe integration, cost contracts, and user management |
| FINANCE | Finance and accounting staff | Payouts, bank balance, registers — plus the shared data views |
| OPERATIONS | Store and till operations staff | Stores and terminals, payment links, virtual accounts — plus the shared data views |
| COMPLIANCE | Risk and compliance officers | Compliance alerts, audit logs, disputes — plus the shared data views |
| USER | Anyone who only needs to look | The shared data views: dashboard, payments, reports |
A user can hold more than one role; they see the union of what each role grants. The same rules are enforced on every API call, not just in the menu — a role that cannot see an area cannot call its endpoints either.
Two rules to know:
- Only administrators manage users, and nobody can change their own roles.
- You can only grant roles up to your own authority — an administrator cannot create a user more privileged than themselves.
Managing users in the dashboard
Administrators manage the team on the Users page: create users, edit roles, reset passwords, unlock accounts, reset a lost authenticator, and disable accounts that should no longer sign in.
User management API
The same operations are available as REST endpoints. They are authenticated with your
dashboard session's bearer token (Authorization: Bearer <token> — the token your browser
session holds after sign-in), not with the X-API-Key used by the payments API.
| Method | Path | Who | What |
|---|---|---|---|
POST | /api/users | Admin | Create a user |
GET | /api/users | Any role | List users you can see (scoped to your merchant) |
GET | /api/users/{id} | Any role | Get one user |
GET | /api/users/me | Any role | Your own profile |
PUT | /api/users/{id} | Admin (own profile: anyone) | Update display name, email — and, for admins, roles and enablement |
PUT | /api/users/{id}/password | Admin | Reset a password |
POST | /api/users/{id}/unlock | Admin | Unlock a locked account |
POST | /api/users/{id}/mfa/reset | Admin | Force authenticator re-enrollment (lost device) |
DELETE | /api/users/{id} | Admin | Disable an account (soft delete) |
Create a user
curl https://api-live.kcpboundless.com/api/users \
-H "Authorization: Bearer <your-session-token>" \
-H "Content-Type: application/json" \
-d '{
"username": "jane.finance",
"password": "a-strong-password-1",
"displayName": "Jane Kim",
"email": "jane@yourcompany.example",
"roles": ["FINANCE"],
"merchantExternalId": "your-merchant-id"
}'
rolesaccepts the names from the table above. If omitted, the user is created asUSER.merchantExternalIdis your merchant identifier; users you create always belong to your own merchant account.- Passwords must be at least 12 characters and include both letters and numbers.
The response returns the created user:
{
"id": 42,
"username": "jane.finance",
"displayName": "Jane Kim",
"email": "jane@yourcompany.example",
"enabled": true,
"locked": false,
"roles": ["ROLE_FINANCE"],
"merchantExternalId": "your-merchant-id",
"merchantName": "Your Company",
"createdAt": "2026-08-19T03:10:00Z",
"updatedAt": "2026-08-19T03:10:00Z"
}
Role names are returned with a ROLE_ prefix; requests accept either form.