Permissions
Permissions define what an API key can do after authentication succeeds. SHM evaluates the role, ownership, and requested resource before every API operation.
Where to find it: Documentation > Hosting Manager > API > Permissions.
Available to: Anyone reading the public documentation. The related SHM action still follows the role stated on its page.
What this page does
Permissions define what an API key can do after authentication succeeds. SHM evaluates the role, ownership, and requested resource before every API operation.
Before you start
Examples use placeholder accounts, domains, addresses, and credentials. Replace them deliberately, and never paste passwords, API keys, tokens, or private keys into tickets or shared notes.
Why use it — and when not to
Use Permissions to understand or plan the supported workflow. Do not treat an example as authorization or as proof of the current state on a particular SHM server.
Role model
| Role | Typical API scope | What it should not be used for |
|---|---|---|
| Root | Server-wide administration, package and feature policy, account lifecycle, reseller management, service state, security, backups, licensing, and provider operations. | Do not use root keys for customer-owned integrations that only need one account. |
| Reseller | Delegated customer accounts, reseller package limits, account provisioning where allowed, and support workflows for owned accounts. | Do not use reseller keys to change server-wide services, licensing, root-only security, or unrelated reseller accounts. |
| User | The authenticated account surface: domains, DNS, SSL, files, mail, databases, backups, logs, resource usage, runtimes, and allowed self-service tools. | Do not use user keys for other accounts or provider-level policy. |
Permission checks
- Path ownership is checked for account endpoints that include {username}.
- Reseller operations are limited to delegated accounts and package policy allowed by the provider.
- Root-only endpoints can affect server-wide state and should be restricted to trusted automation.
- Feature profiles and packages can hide or deny tools even when the account exists.
- State-changing operations should be audited by the calling system with target, operator, request time, and result.
Choosing a scope
| Integration need | Recommended API scope |
|---|---|
| Billing platform creates and suspends customer accounts | Root API or a carefully limited reseller API if the provider delegates provisioning. |
| Reseller portal manages owned accounts | Reseller API. |
| Customer portal edits DNS, mailboxes, SSL, backups, or files for one account | User API. |
| Monitoring checks service status or resource pressure | Root API for server status; User API for one customer account. |
| Support dashboard inspects logs, delivery reports, backups, and resource state | Use the narrowest role that can see the target customer. |
How to use it
- Identify whether the task is server-wide, reseller-scoped, or limited to one account.
- Open the page that owns the resource instead of using a nearby page with a similar name.
- Read the page-specific prerequisites and impact before changing anything.
- Verify the result in SHM and from the customer-facing service.
Result and next check
Reading this page changes nothing in SHM. Follow the linked workflow only after confirming the role, target, and expected impact.
Theme color