Plesk separates the customer from the subscription: a customer can hold several subscriptions, and a subscription is the thing that has a hosting plan and a domain. A billing integration must map its own service to a subscription rather than to a customer, or suspension and renewal will act on the wrong scope.
Plesk's object model is the first thing to get right, and it is where integrations written for cPanel go wrong when they are ported. Plesk documents its REST API at docs.plesk.com.
| Your record | The Plesk object | Why |
|---|---|---|
| Customer | Customer | One person or company who signs in and may hold several things |
| Service | Subscription | The billable unit: a plan, a domain, resources — the thing suspended when unpaid |
| Product | Service plan | The template resources come from |
If you map your billable service to the customer, then suspending for non-payment takes down everything that customer has, including the subscriptions they are paid up on. That is an expensive mistake to make once.
Keep the relationship one-to-one and enforce it. A customer who buys a second hosting package gets a second service in your system, mapped to a second subscription. Anything else makes it impossible to answer what a particular invoice is for, and makes suspension ambiguous.
A Plesk service plan defines resource limits, and a subscription created from it can be changed afterwards — in Plesk, directly, by somebody with access. Your system's idea of what a customer is entitled to and Plesk's idea can therefore diverge silently.
The honest response is to read rather than assume: when you show a customer what they have, show what the panel reports, and mark clearly when it was last read. A figure your billing system believes is not a figure the server agrees with.
Plesk has its own login for customers. Your portal can link to it, and where the panel supports a session-handover mechanism you can make that link one-click. What your portal should not do is hold the customer's panel password so it can log in on their behalf. Storing a customer's password to replay it later is a credential you cannot rotate, cannot audit and cannot explain in a breach.
If you offer a sign-in-to-panel button, treat whatever the panel gives you as a bearer credential: do not log it, do not store it, do not put it in a URL of your own, and let it be used once.
GENV ships a Plesk adapter configured with a host and an API key. As with every provider module in the current build it is exercised against a stand-in and not certified against a live Plesk installation, and effecting actions are unrouted, so nothing in the shipped build can change a real Plesk server.
Map the plan the customer receives. If you resell at a level where your customer gets a reseller account themselves, then their reseller plan is the product and their own sub-accounts are not your billing concern.
As two services with two different connections. Keep the server recorded on each, and never assume a customer is on one platform because their first service was.
Some flows allow it, but doing so makes the failure case harder: if the call is lost you do not know whether you created a customer, a subscription, both, or neither. Creating the customer first, idempotently, then the subscription, is easier to recover.
Official documentation, each requested on 21 September 2026. Provider behaviour changes; check the source before relying on a detail.