Resellers
Resellers sell your servers to their own customers, under their own brand. /admin/resellers lists them with how much of each quota they use. Managing them needs the “Manage resellers” permission.
Adding one
New reseller with a new email creates an account and sends it a sign-in invitation.
To make an existing customer a reseller, use their email, or click Make reseller on their customer page. They keep their account, password, two-factor and servers, and get the reseller pages next to their own servers; no invitation is sent. The company name you enter is the brand their customers see. Their own servers count towards the reseller’s quotas.
A staff account can’t be a reseller, and a customer who buys through another reseller has to be moved back to you first.
Terms
| Term | Notes |
|---|---|
| Quotas | Servers, vCPUs, memory, disk and IPv4. Empty means no limit. Usage covers everything the reseller and its customers own, including floating IPs they hold without a server. A floating IP can only be taken within the IPv4 quota, and only in a location the reseller sells in. |
| Customer limit | How many customers the reseller can sign up: 500 unless you set another number with maxCustomers (PATCH /api/v1/admin/resellers/<id>; null goes back to 500). It only stops the reseller signing customers up; you can still move customers to it yourself. |
| Locations | The node groups they may sell. None means nowhere. |
| Packages | The packages they may sell |
| Status | Active, or Suspended: no new servers, customers or floating IPs, no branding or nameserver changes, and the reseller can only look at its customers’ servers, not change them. Existing servers keep running, and its customers can still use them. |
The terms are checked every time a server is created for a reseller or one of its customers, including when staff create it. The New server page shows usage after the new server and why it would be refused. A quota.near_limit webhook fires when a quota passes 90%.
Their customers
On a reseller’s page you can add a direct customer to it, or make one of its customers direct again.
What resellers get
Resellers sign in like customers, with their own servers and account, plus a Reseller section:
- Overview: usage against quotas, the locations and packages they may sell (with the IDs a billing module needs), and a “Connect your billing panel” guide.
- Customers: sign customers up with an optional billing ID (the client ID in their own billing), and open each one’s servers.
- New server: only allowed packages and locations. Placement always picks the node.
- Webhooks about their own customers (never transfers, which would reveal nodes).
- Usage: server-days per package and traffic per customer for the last three months, with a CSV download for invoicing.
On their customers’ servers they can do everything the customer can, plus Suspend, Unsuspend, Terminate, change package, add addresses and lower speed limits. Adding or resetting traffic is yours alone: a reseller asks you for a top-up. A reseller can only unsuspend servers it suspended itself: one you suspended, or one suspended automatically for running out of traffic, stays suspended until you lift it or add traffic. They can give their customers a self-service allowance, limited to their own packages and locations.
White label
Under What your customers see on their overview, a reseller sets:
| Setting | Notes |
|---|---|
| Brand name | Shown in the panel header and emails to their customers, 2–40 characters |
| Billing link | Where “Open billing” points on a suspended server. Without it, the panel says “Contact reseller”. |
| Support email | Used in emails to their customers |
| Nameservers | 2–4 names that resolve to your nameservers through glue records |
Their customers see the reseller, never you.
Billing
A reseller’s own WHMCS or Blesta can run everything through the API with a Billing module token. See Connecting a billing panel.