API & integrations

The web interface and the API are the same thing: the interface calls exactly the API that is exposed to integrations, with no privileged shortcut. Anything you can do on screen is available over HTTP.

API tokens

Tokens are for unattended integrations (billing systems, scripts). Only admins can create them.

1. In the admin interface open Panel → API tokens.
2. Give the token a name and an expiry (mandatory, at most one year).
3. Copy the token. It is shown once; the panel stores only a hash. If you lose it, revoke it and create another.

Use it as a bearer token against the admin port (the API is not exposed on a separate port):

curl -sS -H "Authorization: Bearer <token>" https://panel.example.com:2087/api/conexion

Requests without that header get 404. The browser cookie is never accepted on /api/.

Revoke a token at any time in the same screen; it stops working immediately. Resetting the creating admin's password or second factor also revokes their tokens. Tokens that are not used expire like any other; an expired token that was real is not counted as an attack.

What a token can and cannot do

A token never receives, sees or sets anyone's password or second factor. Operations that create or move credentials, or that open a session on something (terminal, mailbox, database, impersonation), answer 403 with "this operation cannot be done with an API token: sign in to the panel". Everything else an admin can do is allowed, including creating and suspending clients.

Creating a login for a customer is done as follows:

• A token can create the sign-in only for an account that was itself created by a token, only with role client, and only if the account has no sign-in yet.
• The login is created without a password. The customer receives an email with a one-time link (valid one hour) to choose their password and enroll their second factor. The link is not consumed by link-scanners that merely open it; it is spent by submitting the new password.
• A password reset from an integration sends a new link to the recovery email stored on the account. Changing that email requires a person with their own password.

Examples

Field names are those of the API (Spanish identifiers):

H="Authorization: Bearer <token>"
B=https://panel.example.com:2087/api

# create a client, then a site
curl -sS -H "$H" -H 'Content-Type: application/json' -d '{"cliente":"acme"}' $B/clientes
curl -sS -H "$H" -H 'Content-Type: application/json' \
  -d '{"cliente":"acme","domain":"example.com","aliases":["www.example.com"]}' $B/sitios

# assign a plan
curl -sS -H "$H" -H 'Content-Type: application/json' -d '{"plan":"basic"}' $B/clientes/acme/plan

# suspend / reactivate (these SET a state; repeating them is safe)
curl -sS -H "$H" -X POST $B/clientes/acme/suspender
curl -sS -H "$H" -X POST $B/clientes/acme/activar

# consumption against the plan
curl -sS -H "$H" $B/clientes/acme/uso

Listings are paginated by cursor (GET /clientes?desde=<last>&limite=200; the limit has a hard cap of 200).

Error codes follow the same meaning as in the interface: 402 paid feature, 403 not allowed or a token-restricted operation, 409 conflict or a prerequisite is missing (for example "this account lives on node X"), 429 wait before repeating, 507 out of disk quota or inodes. See the FAQ.

WHMCS

A WHMCS server module is provided in the integraciones/whmcs directory of the release. Pure PHP, no Composer; needs the curl extension.

1. Copy modules/servers/controlpanel/ into WHMCS modules/servers/.
2. Create an API token as above (name it "WHMCS").
3. In WHMCS: Setup → Products/Services → Servers → Add New Server, type controlpanel. Hostname panel.example.com:2087 (no https://; the module always uses HTTPS), Password = the token (WHMCS stores it encrypted). Leave Username and Access Hash empty. Test Connection must succeed.
4. On the product, Module Settings → Plan: the exact name of a plan that exists in the panel (empty = no plan).

The customer's email must be filled in WHMCS before the account is created: it is where the activation link goes.

TLS is always verified. While the panel's certificate is self-signed, install it in the trust store of the server that runs WHMCS; there is no option to skip verification. The module has not yet been exercised against a production WHMCS; test it on a staging WHMCS first.

Cloudflare

You can mirror your DNS zones to Cloudflare as a secondary. The panel's own DNS is always the source of truth; Cloudflare is only a copy, and changes made at Cloudflare are overwritten by the next sync.

• Admin-only, one Cloudflare account per node (DNS → Cloudflare). The account belongs to the hosting operator who runs the node, not to each end customer. A customer who wants their own Cloudflare account just changes the name servers at their registrar and removes the zone from the node.
• Create a Cloudflare API token limited to the zones and permissions needed, paste it once; it is stored encrypted and never shown or logged. The panel cannot verify a token's scope, so give it the narrowest scope you can.
• You choose zone by zone which to mirror. There is no "mirror everything" switch.
• Only zones that already resolve to this server can be mirrored; this is checked against a recursive resolver (not the panel's own DNS), and re-checked daily. A zone that stops pointing here is dropped from the mirror and its records are removed from Cloudflare.
• A zone that already exists in your Cloudflare account is rejected, not adopted: the sync would delete any record not present in the panel.
• The panel warns about the account's zone quota before it fills, reading the limit from the account itself.
• Sync now queues the zone; the queue processes about one zone per minute.
• A Cloudflare failure never affects your own DNS.