Provisioning Without the Manual Work
A customer orders hosting through WHMCS. Somewhere behind that order form, a real hosting account has to appear on a real server: a domain provisioned, a website configured, PHP set up, SSL issued. If that step is manual, every order is a support ticket waiting to happen — a forgotten SSL, a plan that never matches what the customer paid for, a suspend that does not actually suspend anything on the server.
The Panelica WHMCS Server Module closes that gap. It is an official provisioning module that connects WHMCS directly to a Panelica server through the Panelica External API, so the entire hosting account lifecycle — from the first order to the final termination — happens automatically, with no admin sitting between the two systems.
What Is the Panelica WHMCS Module
The Panelica WHMCS module is a server provisioning module for WHMCS that automates hosting account creation, suspension, termination, plan changes, and password resets on a Panelica server. It communicates with the panel exclusively through HMAC-SHA256 signed API requests, so account credentials and API secrets never travel over the wire in plain form. It requires no ionCube loader and no third-party libraries — just the PHP extensions WHMCS already ships with.
The Full Account Lifecycle, Automated
Every action a hosting business normally performs by hand after an order comes in is mapped to a WHMCS module function that talks to the Panelica External API:
| WHMCS action | What happens on the Panelica server |
|---|---|
| Create | Hosting account is created on the selected plan; the ordered domain is provisioned as a website with nginx, Apache, PHP, and a Let's Encrypt SSL certificate. If website provisioning fails, the account is rolled back automatically so a retry starts clean. |
| Suspend / Unsuspend | The account is suspended or re-activated on the panel — not just flagged in WHMCS. |
| Terminate | The account and all of its panel resources are deleted. |
| Change Password | The panel login password is updated to match WHMCS. |
| Upgrade / Downgrade | The account is moved to the new Panelica plan and kernel cgroup limits are re-applied instantly — no manual resource adjustment. |
| Usage Update (nightly) | Disk and bandwidth usage, plus current limits, are synced back into WHMCS for accurate billing and overage alerts. |
The client area also gets a live overview: a disk usage gauge, monthly bandwidth consumption, and counts of domains, email accounts, databases, and FTP accounts, alongside a panel login button — all pulled from the server in real time, not cached at order time.
Two Plan Modes
Not every hosting business wants the same relationship between its billing system and its plan definitions. The module supports two:
| Mode | How it works |
|---|---|
| Existing Plan | Pick a plan already defined on the panel from a live dropdown inside the WHMCS product. Classic behaviour — the plan lives on the panel, WHMCS just assigns it. |
| Managed by WHMCS | Select "Managed by WHMCS" and define every resource directly on the WHMCS product: disk quota, bandwidth, CPU percentage, memory, max processes, disk I/O, website/database/email/FTP counts, Docker container limit, PHP memory, and SSH access level. |
In managed mode, the module creates and versions a plan on the panel automatically. When a resource value changes in WHMCS and an admin runs a package change, every account on that product moves to a fresh plan version and the Panelica backend rewrites the account's kernel cgroup limits immediately — CPU percentage through cgroups v2 cpu.max, memory through memory.max, and process count through pids.max. These are kernel-enforced limits, not soft settings a tenant can work around from inside their own account, which matters when a WHMCS product change is supposed to actually change what a customer can consume. Superseded plan versions are garbage-collected automatically once no account references them, and managed plans stay out of the manual plan dropdown so the two modes never collide. Hosting companies evaluating how reseller-grade plan and role management should work in a modern panel will recognize the pattern — the difference here is that WHMCS becomes the single source of truth for the plan itself.
One-Click Login for Your Customers
With a full-access API key (scope *:*), WHMCS shows a "Login to Panel" button in both the admin service page and the client area. One click and the customer lands inside their hosting panel — no password prompt, no separate login flow to explain in a support article. Under the hood, the module requests a one-time, single-use token valid for five minutes from the Panelica server, and WHMCS redirects the browser straight to the panel's auto-login endpoint.
Single sign-on requires a Panelica server build that exposes the SSO endpoint (external-server 1.0.5 or later). On an older panel build, SSO is simply hidden and the rest of the module works exactly the same.
Client Self-Service Without Panel Access
Give the WHMCS API key broader scopes and the client area gains self-service tabs that only appear when the key actually carries the matching permission — a key limited to billing integration still shows a clean, overview-only client area:
- Email accounts — create, list, and delete mailboxes with a quota, without a panel login.
- FTP accounts — create, list, and delete FTP users.
- Subdomains — create, list, and delete subdomains under the account's domain.
Database self-service is intentionally read-only, showing a count on the overview rather than a create form. The Panelica External API's database endpoint adds a user to an existing domain database rather than provisioning a new one, so the module does not pretend to offer something the panel-side API does not support yet — that limitation is documented, not hidden.
Security by Design
Every request between WHMCS and the panel is signed, time-boxed, and logged. The module signs each API call with HMAC-SHA256; the API secret itself is never transmitted. Signed requests are valid for five minutes, so an intercepted request cannot be replayed later — this also means the WHMCS server's clock needs to be accurate via NTP, or requests will fail with a timestamp-expired error. Every API call is recorded in the WHMCS module log with credentials masked, so admins can audit exactly what happened on an order without exposing secrets in the log itself. Fresh Panelica installs that still serve the panel on a self-signed certificate are handled automatically: the module retries with certificate verification disabled while keeping the HMAC signature check in place, so a new server works out of the box while still authenticating every request.
Installation
The module drops into the standard WHMCS server module directory, no activation step required:
panelica.php
whmcs.json
lib/PanelicaAPI.php
templates/overview.tpl
accounts:read, accounts:write, accounts:delete, domains:write, plans:read, plans:write, and bandwidth:read. An IP whitelist restricted to the WHMCS server is recommended. The panel shows the API key and secret only once — copy both immediately.Requirements and Compatibility
| Requirement | Details |
|---|---|
| WHMCS | 8.0 through 9.0.x. Developed and tested on WHMCS 9.0.6. On WHMCS versions predating the 8.0 SSO framework, single sign-on is hidden and the rest of the module functions normally. |
| PHP | 7.4 or newer, tested on PHP 8.3. The module contains no PHP 8-only syntax. |
| PHP extensions | curl, json, hash — all standard. No ionCube loader required. |
| Panelica server | Any currently supported version. Single sign-on additionally requires external-server 1.0.5 or later. |
| Panelica license | The API Access feature must be enabled on the license. |
Known Limitations
Two panel-side behaviors are worth documenting rather than glossing over. First, the inode_quota field is ignored by the plan update endpoint — the module still sends it, but the panel does not persist that one column, while roughly twenty other resource fields apply and are verified at the kernel level. Second, PHP's max_execution_time is written to the PHP-FPM pool correctly on account creation, but a later change to that specific value through a package change is not re-applied until the account's next full configuration regeneration, even though CPU, memory, I/O, and process limits update live on every package change. Everything else in managed mode — CPU percentage, RAM, process count, I/O, network, container limits, PHP memory, upload and post size, quota mode, WAF setting, SSH access level, and the advanced overrides — is applied and kernel-verified on both create and change.
Why This Matters for Hosting Businesses
Every hour an admin spends manually creating, suspending, or resizing a hosting account is an hour not spent growing the business. For a hosting company or reseller running WHMCS, the value of a provisioning module is not a feature list — it is the number of tickets that never get created because the account did the right thing automatically the moment the invoice was paid. That is the same calculation behind the economics covered in our breakdown of what large account counts actually cost over a year: licensing is one line item, but operational overhead compounds quietly in the background until someone adds it up.
For a reseller building a branded hosting business, or anyone following a guide on how to start a web hosting business, the WHMCS module removes one of the biggest early bottlenecks: the gap between "customer paid" and "customer has a working website." Combined with the panel's own white-label branding, a WHMCS storefront and a Panelica backend can look and behave like a single, seamless product to the end customer — while the two systems stay in sync automatically instead of through manual reconciliation.
Getting Started
The Panelica WHMCS Server Module is open source and available on GitHub. Installation takes three steps — create an API key with the right scopes, add the server in WHMCS, and create a product — and the Test Connection button confirms the setup before a single customer order ever depends on it.
Frequently Asked Questions
Does the Panelica WHMCS module require ionCube or any paid dependency?
No. The module is plain, readable PHP using only the standard curl, json, and hash extensions that WHMCS already requires. There is no ionCube loader and no third-party library to install.
What happens if a website fails to provision during account creation?
The module rolls back the account automatically, so a customer retrying the same order starts from a clean state instead of hitting a duplicate or half-configured account.
Can customers manage email, FTP, and subdomains without logging into the panel?
Yes, if the WHMCS API key carries the matching scopes. The client area shows self-service tabs for email accounts, FTP accounts, and subdomains only when the key's permissions allow it; database management stays read-only because of a current panel API limitation.
Does upgrading or downgrading a plan actually change what a customer can use, or just what WHMCS shows?
It changes what the account can actually consume on the server. CPU, memory, and process limits are enforced by the Linux kernel through cgroups v2, and a package change rewrites those kernel limits immediately, not just a database record in WHMCS.
Which WHMCS and PHP versions are supported?
WHMCS 8.0 through 9.0.x, developed and tested on WHMCS 9.0.6, and PHP 7.4 or newer, tested on PHP 8.3. Single sign-on additionally requires a Panelica server running external-server 1.0.5 or later.