Registering a Plesk server

This is the step that replaces VPS provisioning: mint a per-server API key, point the module at a Plesk box you already run, and pick how it verifies TLS.

1. How the module talks to Plesk

Every operation runs over the Plesk REST API at https://host:8443/api/v2, authenticated with a per-server API key over TLS. There is no SSH, no cloud-init, and no Impulse-built control plane on the box — the Plesk server you already run is the platform. The only Impulse code that runs on it is what you choose to install: the file-service daemon and the optional Imunify status reporter.

Three transports share that one key:

• REST v2 for the native surface (subscriptions/domains, clients, databases, DNS records, certificates, /server).
• The CLI-gateway (POST /api/v2/cli/{util}/call) for the large non-REST surface — email, SSL issuance, PHP version, subdomains, WordPress, Git, backup creation and more.
• Legacy XML-RPC where it is cleaner than the gateway — FTP accounts, log rotation, and the one-time sessions behind single sign-on.

Test connection records the Plesk version on the server card. DNS records use the native REST endpoint where the build has it (Plesk 18.0.49 and later) and fall back to the CLI-gateway otherwise; databases use the native REST database endpoints (Plesk 18.0.69 and later).

No SSH, ever

ImpulsePlesk never connects to your Plesk servers over SSH — it has no SSH code path and no break-glass toggle. Management is the typed API calls above; there is no free-form shell over the API.

2. Mint a Plesk API token

On the Plesk server, create an API secret key allowed only from your WHMCS server’s IP — in a root shell on the box, or under Tools & Settings → Remote API if your Plesk build has it. The module sends it as the X-API-Key header (the KEY header for XML-RPC):

# On the Plesk server, as root:
plesk bin secret_key --create -ip-address <WHMCS_IP> -description "ImpulsePlesk"

# List / revoke later:
plesk bin secret_key --list
plesk bin secret_key -d <key>

Allowlist the WHMCS IP

Scope the secret key to the WHMCS server’s public IP. If WHMCS is dual-stack, allowlist both its IPv4 and IPv6.

3. Add the server in WHMCS

Open ImpulsePlesk → Infrastructure → + Add Existing Server:

1. Enter a Name label, the Panel hostname (FQDN or IP) and the API port (default 8443).
2. Pick a region slug — a Core region — so placement and env aggregation line up with your other Impulse modules.
3. Paste the key into Plesk API key (X-API-Key). It is stored encrypted at rest.
4. Optionally set a capacity (0 = unlimited), a shared IPv4 and shared IPv6 used for new sites, and expected nameservers for this server (overriding the default under Settings → General & Access).
5. Choose a TLS mode (see the next step).
6. Click Add server.

The host is strictly validated

The panel hostname must be a plain domain name or IP address — no scheme, port or path. It is validated at add and edit time because it is later embedded in the file-service installer that runs as root on the box.

4. Choose a TLS mode

Pick how the module verifies the Plesk endpoint’s certificate:

• Verify certificate (CA) — use this when the Plesk panel has a real, publicly-trusted certificate on :8443.
• Skip verification (self-signed) — use this for the default self-signed Plesk certificate. The connection is still encrypted; it just isn’t chain-validated.

If your Plesk panel serves a real certificate, prefer CA verification. The file-service daemon you install later uses a separate, pinned TLS model (trust-on-first-use) covered on its own page.

5. Test the connection

Open the server’s menu and choose Test connection. This authenticates GET /api/v2/server with your key and captures the running Plesk version. A green result confirms the key, port and TLS mode are all correct. (Once the file-service daemon is installed, the same test also checks it.)

Now the box is a placement target

A tested, reachable server is eligible to receive provisioning. Register as many Plesk boxes as you operate — each carries its own key, region, capacity and shared IPs, and the module resolves the target server itself at provision time: the least-full healthy server, in the order’s region when the order names one (an order for a region with no capacity fails rather than landing elsewhere).

If the test fails, the usual causes are the key not being allowed from the WHMCS IP, the wrong port, or a TLS-mode mismatch (try Skip verification for a self-signed cert). See Troubleshooting for the full matrix.