Giving somebody access

You can let other people look at, or work in, your account without sharing your password. You invite them at their own email address, choose what they may do, and change or withdraw that later.

Never share your own login. An invitation is always better: you can see who has been in, you can take somebody out again, and they use their own password and their own two-factor authentication.

Inviting somebody

1. Go to Access in the menu and open your customer name.
2. Under Give somebody access, fill in the email address.
3. Pick a role (what each one may do is below).
4. Optionally pick an end date: 24 hours, 7 days, 30 days, or none.
5. Click Send invitation.

The form slides in beside the list rather than over it, so you can keep seeing who already has access while you type — usually the very thing you wanted to check. If the invitation is refused, the form stays open with the reason in it, next to the address it is about.

They get an email with a link. The link is valid for 7 days and can be used once.

You never create a user here yourself. If the address already has a login with us, your account is added to it. If it does not, the person chooses their own password. You are not shown which of the two it was — deliberately: otherwise this screen would be a way of finding out which email addresses are known to us.

Which language the invitation arrives in

The language of whoever receives it, not yours.

If the person you invite already has a login here and has chosen Dutch or English, the invitation arrives in that language — even if you are using the panel in the other one. If we know nothing about the address (the normal case for a new customer), we use the language of the screen you are typing on, and remember what that person's browser asks for the first time they sign in.

The same is true of everything that follows: ownership transfers, "your access has ended", and everything on the Email we send you page.

The roles

Everybody may always manage their own password and two-factor authentication. You cannot switch that off, and that is on purpose: somebody else's account security should not depend on you.

You can change a role later in the list under Access. It takes effect immediately, even if that person is signed in at the time.

Temporary access

Giving an agency or a contractor access for one job? Set an end date. Once that date has passed the access stops working immediately — on their very next click. There is nothing to clean up and nothing to remember.

The entry is kept, so you can still see later who did what and when. If you want to give somebody longer after all, just pick a new end date; that makes the access live again.

Withdrawing access

Click Withdraw next to the name. That person is out straight away and gets an email saying the access has ended. Their login still exists — only your account has been taken out of it.

Open invitations

Below the list are the invitations that have not been used yet.

• Send again sends the mail once more, with a new link. The old link stops working.
• Withdraw makes the link invalid.

Transferring ownership

There is always exactly one owner. Closing the business, or handing it to a colleague? Then you transfer ownership — in two steps, so it can never happen by accident:

1. You designate somebody who already has access (under Transfer ownership). You confirm with your own password — and with your code if you use two-factor authentication.
2. They get an email and confirm themselves.

Ownership only changes hands after that second step. You then become Full management, or you are removed entirely — you choose that in step 1. As long as the other person has not confirmed, nothing changes.

While a transfer is pending you can withdraw it, and the other person can decline it. After 7 days without an answer the designation lapses on its own.

The same list from the command line

If you run a panel yourself and want to check a customer's access without signing in, the API answers exactly what the screen shows:

curl -sS -H "Authorization: Bearer $CORECP_API_KEY" \
  https://panel1.corecp.dev/api/v1/customers/web1/members | jq '.[] | {email, profile, expires_at}'

{"email":"anna@test100.nl","profile":"owner","expires_at":null}
{"email":"agency@example.com","profile":"technical","expires_at":"2026-09-01T00:00:00Z"}

Open invitations are under /api/v1/customers/web1/invitations.

An administrator signing in as you

If your hosting provider runs the panel, a member of staff with the right permission can look at your account temporarily the way you see it. It is called signing in as, and there are three things worth knowing about it:

• It never happens quietly. For as long as it lasts a bar across the top of the screen carries both names, and one click ends it.
• A reason is always required. It is a mandatory field and it goes into the audit log under the staff member's name and under yours.
• There is a great deal such a session may not do: change your password or your second factor, reveal stored secrets, or give anybody else access.

For the staff member: the right sits on the membership and is off by default. Turn it on from the person's row under Who has access → May sign in as, or on the panel host:

$ corecp-panel admin impersonation allow colleague@example.com \
    --config /etc/corecp-panel/panel.yaml
signing in as somebody else is granted to colleague@example.com (1 membership(s))

Whoever has just been granted it has to sign in once more: a session that was already open does not carry the grant yet. If it still refuses after that, the dialog itself says why — the message is inside the dialog now instead of nowhere.

What gets recorded

Every action is recorded with who did it, from which IP address and when — including the actions that were refused. As the owner you can see that per person, so you can always check what an agency or a colleague has been doing.

Permissions are not the same as capabilities

A profile says what somebody may do. Your plan says what there is to do. Those are two different things, and they work together:

• Give somebody Mail management on an account whose plan has no mail, and they will not see the mail section. The profile is right; the capability is not in the plan.
• If your hosting provider switches mail on in the plan later, the section appears by itself — nobody has to be invited again.

Which capabilities your account has is on the Settings page of the account. See Settings and capabilities.

Who may see mail delivery and the mailing lists

A Mail management delegation gains two things:

• this account's delivery log — which messages from your domains arrived, were deferred or bounced. Your domains only: somebody typing another account's address gets the same answer as somebody typing a domain that does not exist.
• this account's mailing lists — adding members, and approving or discarding the messages waiting in the moderation queue.

Read-only sees the delivery log and the mailing lists as well, but cannot approve anything, subscribe anybody or remove a list.

The fleet-wide delivery log (Statistics → Mail delivery) is for administrators only: it holds every customer's mail on that server, which is nobody else's business. A customer or delegate typing that address gets a refusal, not an empty screen.

Who may change limits and packages

This is a separate boundary from the profiles above, and it runs by level:

• An end customer never changes their own limits and never grants themselves an exception. Reading is fine: Settings shows exactly which number came from where, so you know what to ask your provider for.
• A reseller builds and edits the customer packages that are theirs, assigns customers to them inside their own ceiling, and can give a customer more for a while — again inside that ceiling.
• Their own reseller package they can read and cannot change. It is what caps them; hiding it would serve nobody, and letting them raise it would stop it being a cap. In the panel it is marked read-only and the save button is off; over the API the answer is reseller_package_admin_only.
• An administrator does everything, with one exception that applies to everybody: a lower level may only restrict. Widening happens at the level where the ceiling is set.

See Building packages and applying them for what is in a package and how to roll a change out.

Who may attach extra names to a website

An extra name is not a small thing: it goes into the website's certificate, and it can route the mail of a whole domain into that website's mailboxes. So it sits with the same permission as managing websites themselves — whoever may add or remove a website may also decide which names it answers on. A colleague with read-only access, or with mail access only, cannot add one.

Two things the server refuses outright, administrator or not:

• a name that is already a website of its own on this server;
• a name that is already another website's extra name.

Two websites claiming the same name is a coin toss over which one answers, and the loser is somebody else's customer.

Common questions

I invited somebody but they got no mail. Check their spam folder first. If the address is right, click Send again; that sends a fresh link. If it keeps failing, contact your provider — they can see in the system whether the message was sent and what went wrong.

Can somebody with two accounts use one login? Yes. One person, one password, several accounts. Somebody who already signs in with us and gets an invitation only has to confirm; no second account is created.

I was invited at my work address but I sign in with a different one. That is fine. Sign in with the login you have and open the link again; it is attached to that login.

Can I forward the link? Better not. For seven days that link is worth as much as a password: whoever holds it can take the access. Invite the right address instead.

Can somebody with limited access read my website's logs? Only somebody who may see the website. The Logs tab sits behind the same right as the website itself, so a delegate with mail management only never reaches it. What is in there is the requests to your site — addresses, the pages they asked for — and that is exactly why it does not come with every login. Whoever may read it may also follow it live and download it: that is the same information through a different door, and a download that asked for less than the screen would be a way around the screen.

Access to what a scanner found, and to a server's integrations

Two permissions from the same list decide who sees the newer screens.

• Files — the malware scanner reports on paths in your own home, so reading what it found needs files: read and quarantining or restoring one needs files: manage. Somebody you gave read-only access to the files can see an infected file and cannot move it, which is the right way round.
• Websites — clearing a website's cache is websites: manage. It is the mildest thing on that list: the next visitor rebuilds what it dropped.

What a server carries — which integrations are licensed, what the database tuning agent proposes — is not on this list at all. Those are administrator screens; a reseller sees the scan results of their own customers and nothing about the machine itself.

Who may put one thing back out of a backup

There are two kinds of backup and they belong to two different people, so they sit behind two different doors.

• Your own backups — the ones you take, to your own destinations — are under Backups on the account. Anybody with backups: read can see them; anybody with backups: manage takes them and restores them. That is an ordinary permission from the list above and you can hand it to somebody.
• The backups the platform takes belong to your hosting company. The Browse the backups screen, which pulls a single file, database, mailbox, DNS zone or crontab out of one, is therefore for your reseller and your hosting company. You cannot delegate it and you cannot see it yourself: the panel answers "no access" there, even for the owner of the account.

If you want to put one thing back without asking your hosting company, you can do it from the command line on the server — see Your own backups. If you do ask them, they do exactly the same from their side, with a dry run that shows what would happen before anything is written.

When an invitation does not go through

Since round 3 the dialog stays open when the server refuses an invitation, with the reason in it — above the address you typed, which also stays where it was. That sounds obvious and was not: the dialog used to close as though the invitation had been sent, and the explanation landed on the member list underneath, which is not what you were looking at.

The same is true of the other dialogs on this page — changing somebody's profile or end date, and transferring ownership. On that last one it counts twice: the likeliest refusal there is a wrong password, and that password is in the dialog that used to close.

Checking what somebody can actually do

You do not have to work it out from the profile name. Every member row and every person's page carries Effective permissions, which reads the panel's own permission rules and shows, for that membership: what it may do, which screens open, and which operations it opens. It changes nothing and the person is not told you looked.

$ corecp-panel authz --atoms | jq -r '.[] | select(.atom == "mail.manage") | .routes[:4][]'
account.mail.quarantine.act
alias.create
alias.remove
mail.delivery

Use it before you reach for Sign in as, which is the heavier tool: that one starts a real session in the customer's name and is written into their audit log twice. Seeing what a customer sees sets the two side by side and says what the customer notices of each (of the first, nothing at all).

When somebody leaves for good

Removing a membership ends what somebody may do. It does not remove the person: their login still exists, they can still sign in, and the panel still holds their sessions, their notifications and every line in the log with their name on it. That is deliberate — a person is meant to outlive any one membership, and somebody who leaves one customer often stays a customer of another.

When the person themself is to go, that is a separate act with a separate page: Personen → the person → Privacy. There you can download everything the panel holds about them, and erase them. The erasure refuses to run while a membership, an open ownership transfer or a customer account is still attached — so the order is always the one this page describes first: end the access, settle what is open, then erase.

Erasing a person, and what stays walks through it and says what survives it, which is one thing: the audit log keeps the address that acted. Customers asking for their own copy are answered by Your data in the panel.