Integrate with WHM using a scoped API token rather than root credentials, grant only the account-management privileges you use, and design for the case where a create request times out. WHM account usernames are short and constrained, so reserve the username locally before you send anything.
cPanel & WHM is a widely deployed hosting control panel, and its API is documented at api.docs.cpanel.net. An integration is straightforward to get working and easy to get subtly wrong in ways that surface months later.
WHM issues API tokens under its own management screen, and a token can be restricted to specific privileges. Do not integrate with a root password. A billing system typically needs to create, suspend, unsuspend, modify and terminate accounts, and to list them — and nothing else. It does not need mail configuration, DNS zone editing or the ability to change WHM's own settings.
Issue a token per integration, not per person, and write down which system holds it. When somebody leaves, you want to rotate one named token rather than wonder which of five is theirs. See API credentials: least privilege and rotation.
cPanel usernames are short, lowercase and restricted in character set, and they must be unique on the server. Two consequences follow. First, you cannot derive a username from a domain without a collision strategy. Second, the collision you care about is your own: two of your customers being provisioned at the same moment onto the same server.
Solve it locally. Claim the username in your own database, keyed on the server and the username, in the transaction that authorises the provisioning request. Then WHM's own uniqueness is a second line of defence rather than your only one.
Suspending an account in WHM is reversible and keeps the data. That makes it the right tool for non-payment. It is not the right tool for abuse in every case — an account suspended for sending spam may need its outbound mail stopped faster than a suspension propagates, and that is an operational decision rather than a billing one. Keep the reasons separate in your records: a suspension for non-payment and a suspension for abuse are lifted by different people on different evidence.
If your system cannot represent "we asked and never found out", it will force this case into success or failure and one of those will be wrong. That is the single most important thing to check before you automate cPanel provisioning.
If you are provisioning under a reseller account rather than root, your token's privileges are bounded by the reseller's own package limits, and account creation will fail when those limits are reached. That failure is a refusal, not an error to retry, and it should reach a person with the actual reason rather than a generic failure. Watch for it especially after you have been selling well for a month.
GENV ships a cPanel & WHM adapter covering create, inspect, suspend, reinstate, resize and terminate, configured with a WHM user and API token and never a root password, with a private-network option for servers not exposed publicly. Its account lifecycle passed against a lab WHM server on 26 September 2026, with a scoped token and synthetic accounts: create, refusal of a duplicate create, suspend and unsuspend, change package, remove, reconciling a create whose answer was lost, and issuing a sign-in session (a session opened in a browser was not part of the test). None of it is routed in GENV yet, so nothing in the shipped build changes an account on your server.
In practice: account creation, suspension and unsuspension, modification, termination and listing. Grant those and stop. If a later feature needs more, add that privilege deliberately rather than starting from full access.
No. Termination destroys data and should be a deliberate act by a person, with a confirmation, after a published notice period. Automating it means a billing bug can delete a customer.
Record which server each account is on, so that moving a customer is a visible change rather than an inference. A system that only records the plan cannot tell you who is affected when a machine is retired.
Official documentation, each requested on 21 September 2026. Provider behaviour changes; check the source before relying on a detail.