Settings
Manage your profile, API clients, users, and the roles that govern access to your BEEM account.
The Settings area is where you manage who and what can access your BEEM account, and with what level of permission. It is split across three sub-pages:
View your own account details — username, email, and Account ID.
Manage API clients (machine-to-machine credentials) used to authenticate calls to the BEEM API.
Manage human users — invite teammates, control access via roles, and restrict logins by IP.
How roles work
A role is a single permission that controls access to one part of BEEM. The same role applies to both the Portal and the API:
- Granted to a user — the relevant section appears in the Portal sidebar and the user can take the actions the role allows. Without the role, the section is hidden.
- Granted to a client (API key) — the corresponding API endpoints accept calls made with that client's credentials. Without the role, those endpoints return a
403 Forbidden.
Roles are additive: a user or client with multiple roles has the combined permissions of all of them. Up to 15 roles can be held at once.
Three access levels are used across the role taxonomy:
| Level | What it grants |
|---|---|
viewer | Read-only access — list and view, but cannot create, edit, or delete. |
operator | Full access — read, create, edit, and delete within the domain. |
approver | Payments only. Independent right to vote on pending approvals. Assign in addition to operator or viewer when the user needs to approve outbound payments. |
Role identifiersEvery role is prefixed with
layer1:role:on detail panels and in the API (for examplelayer1:role:payment:operator). The tables below list each role in short form for readability.
Common integration scenarios
If you're provisioning a client (API key) for a specific integration, start from one of these bundles and add roles only if you need them.
| If you're building... | Assign these roles |
|---|---|
| An inbound crypto integration via Channels | channels:operator, ledger:viewer, hook:operator |
| A Payment Links checkout (pay-in or pay-out) | payment:operator, ledger:viewer, hook:operator |
| Outbound payouts that require approval | payment:operator, ledger:viewer — and assign payment:approver to a separate client or user that will vote |
| A treasury / FX rebalancing bot | conversion:operator, ledger:viewer |
| Read-only reconciliation or reporting | ledger:viewer, channels:viewer, payment:viewer |
| A management API that provisions more clients | client:operator |
| Admin tooling to manage teammates | user:operator |
Principle of least privilegeOnly grant the roles a client or user actually needs. For production integrations, prefer separate clients per workload (e.g. one client for inbound channels, one for outbound payouts) so a compromised key has limited blast radius.
Roles reference
Users
| Role | Description | Use case |
|---|---|---|
user:operator | Create, edit, and delete users | Assign to team leads who need to manage their team's access and information |
user:viewer | View existing users | Assign to auditors or stakeholders to provide visibility into user data without granting modification rights |
UI impact
user:operatorreveals Settings → Users with the Create a user button and edit/delete controls. The holder can invite teammates, change their role assignments, suspend or remove them, and resend invitation emails.user:viewerreveals Settings → Users in read-only mode. The holder can see the team roster but cannot modify it.
API impact
user:operatorauthorises create, update, and delete calls on the user management endpoints.user:viewerauthorises list and get calls on the user management endpoints.
Clients (API Keys)
| Role | Description | Use case |
|---|---|---|
client:operator | Create, edit, and delete API keys | Assign to developers or integration engineers who manage API keys for various services or applications |
client:viewer | View API keys | Assign to stakeholders to provide visibility into API key usage without granting modification rights |
UI impact
client:operatorreveals Settings → Clients with the Create a client button and edit/rotate/delete controls. The holder can mint new API clients, register public keys, edit role assignments, and suspend or delete clients.client:viewerreveals Settings → Clients in read-only mode.
API impact
client:operatorauthorises create, update, rotate, and delete calls on the client management endpoints.client:viewerauthorises list and get calls on the client management endpoints.
Wallets
| Role | Description | Use case |
|---|---|---|
ledger:operator | Create and view account level wallets—your merchant's balances | Assign to users who handle day-to-day payments and manage transaction |
ledger:viewer | View account level wallets—your merchant's balances | Assign to auditors or stakeholders to provide visibility into wallets without granting modification right |
UI impact
ledger:operatorreveals Wallets with the ability to spin up new wallets. The holder can view balances, transaction history, and generate exports.ledger:viewerreveals Wallets in read-only mode — balances and transaction history are visible.
API impact
ledger:operatorauthorises wallet create, list, and get calls, plus balance and transaction reads.ledger:viewerauthorises read-only access to wallets, balances, and transaction history. Required for any reconciliation or balance-check call.
Conversions
| Role | Description | Use case |
|---|---|---|
conversion:operator | Convert between wallet balances | Assign to users who manage balances across wallets day-to-day |
UI impact
conversion:operatorreveals Wallets → Convert. The holder can run quote → execute conversions between wallets (e.g. USDC → EUR).
API impact
conversion:operatorauthorises the conversion quote and execute endpoints.
Channels
| Role | Description | Use case |
|---|---|---|
channels:operator | Create, edit, soft delete, and view channels View channel payments | Assign to users who handle day-to-day payments and manage transaction management |
channels:viewer | View channels View channel payments | Assign to auditors or stakeholders to provide visibility without granting modification rights |
UI impact
channels:operatorreveals Channels → All Channels and Channels → Channel Payments with create, edit, and soft-delete controls. The holder can mint channels (crypto deposit addresses) and view all incoming payments.channels:viewerreveals the same Channels sections in read-only mode.
API impact
channels:operatorauthorises channel create, edit, soft-delete, list, and get endpoints, plus channel-payment read endpoints. Required for any inbound crypto integration.channels:viewerauthorises read-only channel and channel-payment calls.
Payments
| Role | Description | Use case |
|---|---|---|
payment:operator | Create payment links | Assign to users who handle day-to-day payments and manage transaction |
payment:viewer | View payment | Assign to auditors or stakeholders to provide visibility into payments without granting modification rights |
UI impact
payment:operatorreveals Payment Links. The holder can create both pay-in and pay-out links and view their associated payments.payment:viewerreveals Payment Links in read-only mode.
API impact
payment:operatorauthorises Payment Link create, list, and get endpoints. Required for any checkout integration.payment:viewerauthorises read-only Payment Link calls.
Approvals
| Role | Description | Use case |
|---|---|---|
approval-settings:operator | Manage approval rules | Manage your approval rules that should be applied to payments |
payment:approver | Approve or reject payments | Assign to trusted leads responsible for reviewing and approving payments |
UI impact
approval-settings:operatorreveals the approval-rules configuration under Approvals. The holder can define which payments require approval and how many approvers are needed.payment:approverreveals the Pending Approvals queue with Approve / Reject controls on each pending payment.
API impact
approval-settings:operatorauthorises the approval-rule management endpoints.payment:approverauthorises the approval vote endpoint — a client with this role can programmatically approve or reject pending payments.
Hooks
| Role | Description | Use case |
|---|---|---|
hook:operator | Create and view hook destinations View hook event types | Assign to developers or administrators responsible for setting up and managing webhook destinations |
hook:viewer | View hook destinations View hook event types | Assign to users or teams to provide visibility into webhook destination setup without granting editing permissions |
UI impact
hook:operatorreveals Integrations → Hooks with create, edit, and delete controls. The holder can register webhook URLs and subscribe them to event codes.hook:viewerreveals Integrations → Hooks in read-only mode.
API impact
hook:operatorauthorises hook (webhook destination) create, list, edit, and delete endpoints.hook:viewerauthorises read-only hook list and get calls.
Worked exampleA dev provisioning an API client for a crypto-accepting webshop would tick
channels:operator(to create deposit addresses),ledger:viewer(to read balances for the dashboard), andhook:operator(to register a webhook fortransaction-confirmed). They would not assignuser:operatororclient:operator— those are admin roles, not relevant to the integration.