API Overview

API Overview explains the exact SHM Engine address, request anatomy, authorization boundary, and completeness rules used by every public endpoint in this reference.

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

Available to: Anyone may read this reference. Calling an endpoint still requires an API identity whose role, scopes, ownership, source policy, and feature access permit the operation.

What this page does

Use the API for repeatable automation, integrations, support tooling, and monitoring. The public API runs on the SHM Engine HTTPS listener at port 882; a panel hostname without that port is not the direct Engine base used by these examples.

Before you start

Create a dedicated API identity, store its key as a secret, and know whether the task belongs to root, reseller, or one account. Read the current resource before a mutation and obtain real ids from list or context endpoints.

Base URL and path

ItemCorrect valueMeaning
Panel hostpanel.example.comReplace this placeholder with the hostname used to reach SHM.
Engine originhttps://panel.example.com:882Port 882 is part of the direct SHM Engine address.
Public API basehttps://panel.example.com:882/v1Append the documented public path. Keep the /v1 namespace; it is the API contract, not a product-release badge.
Example endpointGET https://panel.example.com:882/v1/accounts/demoReplace path placeholders before sending the request.

The complete-parameter rule

Every endpoint card lists every current path, query, JSON, and query-or-JSON key discovered from the route, handler, manual contract, and public catalog. Each card contains a complete request template with every key, including optional and conditional keys. A separate runnable example may show only one valid workflow when sending every mutually exclusive option together would be invalid.

Request anatomy

PartHow to send itExample
Path parameterReplace the named braces in the URL and URL-encode the value.{username} becomes demo.
Query parameterAppend it after ?; encode names and values.?start=0&length=50.
JSON parameterSend a JSON object with Content-Type: application/json.{"enabled": true}.
Query or JSONUse either accepted location stated by the endpoint, not both unless its workflow explicitly says so.Useful for DataTables and compatibility callers.

What SHM checks

  1. Authenticate the API identity with X-Api-User and X-Api-Key.
  2. Enforce source-IP and key state where configured.
  3. Resolve the effective root, reseller, or user role.
  4. Enforce account ownership, endpoint scopes, feature policy, and target identifiers.
  5. Validate every supplied parameter and conditional dependency.
  6. Run the handler and return a JSON success or error envelope with a request id when available.

Current verified surface

This documentation partitions 590 unique public endpoints into Root API, Reseller API, and User API so each route is shown once. The implementation audit also records private orchestration routes, but those are deliberately absent from the customer API reference.

AI Mode and the API

AI Mode discovers the same public contract through GET /v1/ai/catalog and remains subject to the authenticated role and account. Root Workspace AI can discover every public endpoint except the deliberately excluded AI-key and terminal-session routes. Account AI receives the complete account-safe surface, including DNSSEC, while credential-management, terminal-session, and WHMCS ticket creation remain intentionally unavailable to account chat.

How to use it

  1. Choose the smallest role that owns the task.
  2. Copy the Engine origin with port 882.
  3. Open the matching Root, Reseller, or User API endpoint card.
  4. Review every parameter and the complete request template.
  5. Build one valid workflow request and verify mutations with a follow-up read.

Result and next check

You have a request that reaches the SHM Engine on the correct port, carries every key required by its chosen workflow, and stays inside the intended authorization boundary.

Theme color