Integrations

A hosting platform talks to more than itself. There may be a mail gateway in front of your mail server, part of your DNS may live at Cloudflare, your notifications may go through a Telegram bot, your certificates come from Let's Encrypt or ZeroSSL, and the servers run paid add-ons with licences of their own.

Those five used to sit in five different places — and on the question that matters most, where does the key actually live?, there was no single answer anywhere. The Integrations tab is that answer.

You will find it under Settings → Integrations (https://<your-panel>/integrations). Only a platform administrator sees it: reconfiguring an integration moves where a customer's mail or DNS really goes, and that is not a server administrator's button.

Every card says the same things, in the same order

That is deliberate — it is what makes this a list rather than five separate screens:

1. Status — is it working, switched off, or broken?
2. Where it is configured — on the platform, or per server?
3. Where the credential lives — the file, the database column, the configuration key. Never the value. There is no screen and no API route in CoreCP that can hand back a stored token or password; that is the shape of the API rather than a promise about it.
4. The last error or synchronisation, where there is one.

The two integrations that belong to the installation are at the top. Below them is a bar where you pick one server, and under that are the three that belong to a machine — their key material lives there and nowhere else.

Mail gateways

The named gateway platforms of your installation. Per gateway you see its name, the machines it is made of, its status, how many switches point at it, when it last synchronised and what went wrong.

Manage gateways takes you to the form — the same form that used to live under Settings → Mail gateway. That old address still works: /mail/gateway redirects to /integrations/mail-gateway and keeps the ?org= of your bookmark, so you land on the same node group.

What is deliberately not here is which group, server or account actually goes through the gateway. Those switches live with the object itself: on the server page, on the account page and on an account's mail page. One switch in one place — a copy here would be the first place you looked after flipping it in the wrong one. Read on in Mail that is held back.

Cloudflare DNS

Zones served by Cloudflare rather than by our own nameservers. Each server keeps named API tokens for that: you can have several side by side — default beside one customer's own token, say.

Pick the server in the bar first. You then see, per token, its name, the provider, the Cloudflare account and when it was created — and never the token itself.

Storing a token. Press Store a token, give it a name, paste the token, and optionally fill in the Cloudflare account id new zones are created in. The token travels encrypted to that one server and is stored encrypted there — /etc/corecp/secrets/dns-providers/<name>.enc, owned by root, mode 0600. The panel keeps nothing: the field is emptied the moment you press save.

The token is verified against Cloudflare first and stored only then. If it is wrong or expired the form says so at once — carrying Cloudflare's own answer — and nothing is written.

Removing a token. The button on the row asks first, naming the credential and saying what does and does not happen: zones naming this token can no longer be changed from the panel afterwards, but nothing is deleted at Cloudflare itself.

The same thing from the command line on the server:

corectl dns credential list
# NAME             PROVIDER     ACCOUNT                           CREATED
# default          cloudflare   4e1f9c2b…                         2026-07-07

printf %s '<token>' | corectl dns credential set default --token-stdin \
  --cf-account 4e1f9c2b7a5d8e6f0c3b1a9d7e5f2c40
corectl dns credential delete default

Which zone uses which token is not chosen here but on the domain's own DNS page — see Managing DNS records.

Telegram

The platform's bot status: is a bot configured, what is it called, and are you connected yourself? This card is deliberately read-only. The bot token is in panel.yaml on the panel machine and is read at start-up; there is no button to change it from a browser, and no route that could.

You connect your own chat under My account → Notifications. The button on the card takes you there.

# on the panel machine
grep -A3 '^telegram:' /etc/corecp-panel/panel.yaml
# telegram:
#   bot_username: corecp_alerts_bot
#   bot_token: <it lives here; never in an API answer>

Certificate authorities

Where the chosen server orders its certificates: the primary authority (Let's Encrypt by default here), the fallback (ZeroSSL), whether the ACME account is registered there, the directory URL and the contact address.

This card is read-only as well, and that is a decision rather than a gap. Minting and holding a certificate authority's key material never happens from a web screen in CoreCP. You change it on the machine:

corectl ssl ca show
corectl ssl ca set --directory https://acme.zerossl.com/v2/DV90

Add-ons on this server

The server's own registration: what the machine knows (cPGuard, Releem, LiteSpeed Enterprise, Installatron, JetBackup), whether it is running, and which licence file it needs. Switching one on or off and entering a licence key happens per server, on that server's own Integrations screen — the Manage on the server button takes you there. See Integrations on a server.

corectl integration list
corectl integration show cpguard
printf %s '<key>' | corectl integration credential set cpguard --stdin

What is deliberately not here

Finding something quickly

Press Ctrl/⌘ + K and type the brand: cloudflare, pmg, telegram, zerossl, acme. You land straight on the card.