API

The SHM API Reference is the customer-facing automation manual for provisioning, account operations, reseller workflows, user self-service, service checks, backups, DNS, mail, databases, files, SSL, security, and operational reporting.

Where to find it: Documentation > Hosting Manager > API > API.

Available to: Anyone reading the public documentation. The related SHM action still follows the role stated on its page.

What this page does

The SHM API Reference is the customer-facing automation manual for provisioning, account operations, reseller workflows, user self-service, service checks, backups, DNS, mail, databases, files, SSL, security, and operational reporting.

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 API 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.

Purpose and scope

Use the API Reference when connecting SHM to billing systems, customer portals, provisioning tools, support dashboards, monitoring platforms, or controlled internal automation. The public reference documents stable customer, reseller, and root integration endpoints only. Private panel helpers, private AI runtime routes, and messaging-channel worker routes are intentionally not published as external contracts.

Endpoint details are split by operational scope. Open Root API for server and provider operations, Reseller API for delegated customer management, and User API for account-owned hosting tasks. Each endpoint panel includes permissions, parameters, validation notes, cURL, success examples, error examples, and related SHM UI context.

Reference navigation

PageUse it for
API OverviewUnderstand base URL conventions, request format, response format, public scope, and integration best practices.
AuthenticationLearn which headers are required, how API identities are scoped, and how keys should be protected and rotated.
PermissionsUnderstand Root, Reseller, and User boundaries before choosing an endpoint or creating an API key.
Error FormatRead the standard error structure and learn how to react to authentication, permission, validation, not-found, conflict, and rate/operation errors.
API ExamplesCopy safe request patterns for cURL, PHP, and JavaScript integrations using placeholder data.
Root APIProvider and administrator operations that affect server-wide policy, services, security, licensing, packages, accounts, backups, and operational tooling.
Reseller APIDelegated customer-management operations for resellers, limited by ownership, packages, assigned accounts, and provider policy.
User APIAccount-owned operations for domains, DNS, SSL, mail, databases, files, backups, logs, runtimes, and self-service tools.
  • Start with API Overview to understand request shape and the public automation boundary.
  • Read Authentication and Permissions before creating API keys for staff, resellers, customers, or external systems.
  • Use API Examples to confirm your client sends headers, JSON, and query parameters correctly.
  • Open the role-specific API page that matches the identity you will use in production.
  • For state-changing operations, test in a controlled account first and verify the result in the related SHM UI page.
Do not share real API keys, passwords, customer identifiers, private IP addresses, or production tokens in tickets, screenshots, examples, or documentation. Use short-lived test keys and rotate keys when staff, customers, or integrations change.

How to use it

  1. Identify whether the task is server-wide, reseller-scoped, or limited to one account.
  2. Open the page that owns the resource instead of using a nearby page with a similar name.
  3. Read the page-specific prerequisites and impact before changing anything.
  4. 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