Use the Plesk REST API with reseller and customer accounts

Plesk Obsidian 18.0.79, released 3 July 2026, removed a restriction that had been in place since the REST API launched: only the administrator account could call it. Resellers and customers were stuck on the older XML API, which meant any customer-facing automation — a billing portal that provisions subscriptions, a support tool that reads a client's error log — had to either run as admin or shell out to plesk bin over SSH. That's gone now. If you run a hosting business on Plesk and want customers or resellers to script against their own accounts, this is the release that makes it practical.

This guide covers what actually changed, how to authenticate as a reseller or customer, the new admin impersonation header, and the file and log endpoints that shipped alongside the access change.

What changed in 18.0.79

Before this release, hitting /api/v2/ with anything but administrator credentials returned a 403, full stop. As of 18.0.79:

• Reseller and customer accounts can call the REST API directly, scoped to their own subscriptions — a customer's key can't see another customer's domains, and a reseller's key can't see accounts outside their reseller pool.
• A new X-Impersonate-Login header lets an administrator's API key act as a specific reseller or customer without needing that user's password — useful for support tooling and bulk operations across many accounts.
• New file management endpoints: GET /fs/content (download), PUT /fs/content (upload/ overwrite), PATCH /fs/content (append), plus POST /fs/copy, POST /fs/move, DELETE /fs, and PUT /fs/chmod (Linux only, sets file permissions).
• GET /logs searches a domain's Apache, nginx, or PHP-FPM logs for a pattern and returns matching entries — no more SSH-ing in to grep a customer's error log.

If your server is still on 18.0.75 or 18.0.78, none of this is available — check your version in Plesk > Tools & Settings > Server Information and update first. See fixing Plesk update failures if the upgrade won't complete.

Authenticate as a reseller or customer

REST API calls go to https://<hostname>:8443/api/v2/<endpoint>. Two auth methods work:

1. Basic auth — base64-encoded login:password in the Authorization header. Fine for a one-off test, bad for anything that stores credentials at rest.
2. API keys — created once, sent via the X-API-Key header on every subsequent request. This is what you want for anything long-lived.

A customer or reseller creates their own key by authenticating with their own credentials against the key endpoint:

curl -X POST "https://panel.example.com:8443/api/v2/auth/keys" \
  -u "customer_login:customer_password" \
  -H "Content-Type: application/json" \
  -d '{"description": "billing-portal-integration"}'

The response includes the key exactly once:

{ "key": "78711059-23bb-cf6f-b07f-985e1995d2e2", "id": 42 }

Store it immediately — Plesk does not show it again. From then on, authenticate with:

curl "https://panel.example.com:8443/api/v2/domains" \
  -H "X-API-Key: 78711059-23bb-cf6f-b07f-985e1995d2e2"

A customer key returns only that customer's domains and subscriptions; a reseller key returns everything under that reseller's pool. There's no separate "enable API access" checkbox to flip — if the account can log in, it can mint a key. That's a meaningful shift from the XML API model, where a reseller needed Ability to use XML API explicitly granted on the Permissions tab before any script would work. For the background on that older model, see setting up reseller accounts and plans.

Use admin impersonation for support and bulk tooling

For internal tools — a support dashboard, a batch job that touches every customer on the box — minting and rotating a key per customer doesn't scale. The X-Impersonate-Login header solves that: authenticate as admin, then act as any user by name.

curl "https://panel.example.com:8443/api/v2/domains" \
  -H "X-API-Key: <admin-api-key>" \
  -H "X-Impersonate-Login: acme_customer"

This runs the request with acme_customer's permissions and scope, not admin's — it can't be used to escalate, only to act as a specific lower-privilege account on demand. That makes it a good fit for a support agent's "view as customer" button, or a nightly script that loops over every reseller and pulls their subscription list without storing a key per reseller.

Automate file deploys and log triage

The file endpoints turn the REST API into a lightweight alternative to SFTP or plesk bin for scripted deploys. Upload a file into a domain's webspace:

curl -X PUT "https://panel.example.com:8443/api/v2/fs/content?path=/httpdocs/index.html" \
  -H "X-API-Key: <customer-api-key>" \
  --data-binary @index.html

Set correct permissions afterward on Linux:

curl -X PUT "https://panel.example.com:8443/api/v2/fs/chmod?path=/httpdocs/index.html" \
  -H "X-API-Key: <customer-api-key>" \
  -H "Content-Type: application/json" \
  -d '{"mode": "0644"}'

If you'd rather deploy from a Git repository than push files over the API, Plesk's native Git extension is usually the better fit — see deploying sites with Plesk's Git extension.

For log triage, GET /logs searches without shell access:

curl "https://panel.example.com:8443/api/v2/logs?domain=example.com&type=error_log&pattern=500"
  -H "X-API-Key: <customer-api-key>"

That's the same access a customer would get by tailing their own error logs in the panel, just scriptable — useful for feeding a customer's monitoring stack or auto-flagging 500 spikes without giving them shell access.

What this actually enables

The practical shift is that hosts can now build genuinely self-service tooling without routing every request through an admin-scoped integration:

• A billing platform can let customers manage their own file uploads or read their own logs using a key that's provably scoped to their account, rather than a shared admin key with an authorization layer bolted on top in your own app.
• Support teams can build a single internal tool that impersonates any customer or reseller on demand, instead of storing per-account credentials to answer "why is this domain returning 500s."
• Resellers running their own downstream automation — a control panel skin, a client dashboard — no longer need the XML API's more limited operation set or the "Ability to use XML API" permission dance.

None of this changes reseller plan limits or permissions themselves; a reseller's API key is still bounded by whatever the reseller plan allows. If you haven't set overselling and quota policy correctly at the plan level, review reseller plan setup before you build automation on top of it — a bug in a script now has API-speed access to whatever the account is already allowed to touch.

Next steps

• Set up reseller accounts and plans in Plesk
• Deploy sites with Plesk's Git extension
• Fix Plesk update failures