MOR API Permission Groups

Fine-grained allow lists for hash-protected MOR API methods. Assign a group to integration users so they can call only the API actions you permit.

Overview

What are API permission groups?
An API permission group is a named template of per-method API rights. Each hash-protected API method (for example dids_get, users_get, did_create) can be set to Disabled, Read, or Write inside the group. You assign one group to a user when API restricted is enabled on that account.

When does the group matter?
Permissions are enforced only for users with API restricted turned on. If API restricted is off, the account keeps full access to hash-protected API methods (still subject to normal API settings such as API Configuration, hash authentication, and role-specific rules such as accountant Manage DIDs on Accountant permissions).

Only user and accountant accounts can use API restricted. The checkbox is not shown for resellers, admins, or other user types.

Permission levels

On the group edit screen, each API method has three radio options:

Column in GUI	Value	Effect
Disabled	0	The method is denied for restricted users in this group.
Read	1	Allows methods classified as read-only (for example dids_get, users_get).
Write	2	Required for methods that create, update, or delete data (for example did_create, user_details_update). Also satisfies read-only methods.

Read-only methods in the GUI
For methods that only read data, the Write column is disabled — you can set Disabled or Read only. This matches how the system classifies each action internally.

Methods not listed in the ACL table
Hash-protected methods are included in the group editor. callback_init is shown for compatibility but is marked hash-only — ACL is not enforced for that action (legacy uniquehash behaviour). All other hash-protected actions in the registry are gated when API restricted is on.

Manage API permission groups

Where to open the list
Go to SETTINGS → Setup → API Permission Groups.

You can also open the same list from SETTINGS → Setup → Settings (API tab) via the API Permission Groups link.

Admin only
Only an administrator can create, edit, or delete groups.

Create a group

1. Open API Permission Groups.
2. Enter Name and Description in the bottom row of the table.
3. Click the add icon to create the group.

A new group starts with every method set to Disabled. Open the edit (pencil) icon to configure permissions.

Edit permissions

1. On the list page, click edit for the group.
2. Set Disabled, Read, or Write for each API method (grouped by category in the table).
3. Click Update to save.

VoiceAI DIDs Reader preset
On the edit page, Apply VoiceAI DIDs Reader preset sets all methods to Disabled except:

• dids_get — Read
• system_version_get — Read

Use this preset for integration accountants that should sync DID inventory (for example VoiceAI) without broader API write access. You can adjust individual methods after applying the preset.

Delete a group

1. On the list page, click delete for the group.

A group cannot be deleted while any user still has it assigned. Reassign or clear API restricted on those users first.

Assign a group to a user

1. Go to SETTINGS → Users (or edit an existing user).
2. Create or edit a user or accountant account.
3. Enable API restricted.
4. Choose the group from the dropdown (shown when API restricted is checked).
5. Save the user.

If no groups exist yet, the form shows a link to create one first.

Saving requires a group when API restricted is enabled; otherwise validation fails with API permission group is required when API restricted is enabled.

How enforcement works

When a restricted user calls a hash-protected API action (XML /billing/api/ or MOR API v2 where applicable):

1. MOR authenticates the user (u / hash or v2 login).
2. If API restricted is off for that user, the ACL check passes.
3. If API restricted is on, MOR loads the user's assigned group and compares the method's required level with the permission stored for that method.
4. If the permission is too low or missing, the call is rejected.

Typical denial responses

• XML API: API method not permitted: users_get (action name varies per call).
• MOR API v2 (JSON): same message with HTTP 401.

ACL is not the only gate
Passing the permission group does not bypass other rules. For example, an accountant still needs Manage DIDs (read) on their accountant permission group to use dids_get; otherwise the API returns You are not authorized to manage DIDs even when dids_get is allowed in the API permission group.

Similarly, global settings (Allow API, hash requirements) and data scope (admin vs reseller vs user) still apply.

Example: read-only DID sync user

Typical setup for an external system that only lists DIDs:

1. Create or edit an API permission group; apply VoiceAI DIDs Reader preset (or manually allow Read on dids_get and system_version_get only).
2. Create an accountant user with rights needed for your integration (for DID listing, Manage DIDs read on an accountant permission group).
3. Enable API restricted and select the API permission group.
4. Use that user's credentials for API calls (u + hash, or MOR API v2 login).

The user can call allowed read methods but receives API method not permitted for disallowed actions such as did_details_update or users_get.

Related topics

• MOR API — authentication, hash construction, and method list
• MOR API v2 — JSON API (same ACL rules for restricted users on gated endpoints)
• Accountant permissions — GUI and API rights (for example Manage DIDs) separate from API permission groups
• API Configuration — global Allow API, secret key, and hash settings
• MOR API dids get — DID listing API often used with VoiceAI DIDs Reader preset