Envless sends two kinds of email. Transactional mail carries something only you can act on: a sign-in code, a verification link, a notice that your account changed. Notification mail tells you something happened in a workspace you belong to. Only the second kind has switches, and they live on Preferences under Notifications.
The switches are on your user record, not on a workspace. One account carries one set of preferences into every workspace it belongs to, and nobody else's mail is affected by yours. There is no per-workspace override and no workspace-wide mute.
The six switches
All six are on by default, including for accounts created before they existed. A switch is stored only once you turn it off, so an empty preference map means everything is on.
| Switch | Key | What it covers |
|---|---|---|
| Version published | versionPublished | A version was published, or rolled back, in an environment you can reach |
| Team activity | memberJoined | Someone joined, or left, a workspace you belong to |
| Environment exposure | environmentExposed | An environment started, or stopped, being served as an exposed encrypted feed |
| Billing and plan | billing | Upgrades, downgrades, plan changes, renewals, cancellations, a failed payment, a recovered payment, the custom-domain plan grace notice, and the confirmation that a workspace was deleted |
| Domains and delivery | infrastructure | A custom domain was verified, failed verification, or was removed |
| Welcome and onboarding | onboarding | The welcome message when you sign up, and the one when you join a workspace |
The custom-domain plan grace notice is billing, not domains. Every other custom-domain email is under Domains and delivery, but the one that says your plan no longer includes a custom domain is sent to the billing recipients and is silenced by the Billing and plan switch. Turning off Billing while you run a custom domain means you will not be told that the grace window has started.
A switch is not the only filter
Turning a switch on does not mean you receive everything in that family. Two other filters run first, and both can leave you off a mail you asked for.
| Filter | Effect |
|---|---|
| Permission | Billing mail goes only to members whose role holds billing:manage or workspace:update. Domain mail needs workspace:update. Team activity needs members:read. A role without the permission never receives that family, whatever the switch says |
| Product access | Version and exposure mail for a private product goes only to members with an explicit grant on it. Members of the workspace who cannot open the product are not told about its versions |
You are never emailed about your own action. The person who published the version, rolled it back, or exposed the environment is filtered out of the recipient list by email address before the mail goes out, so a one-person workspace is quiet by construction.
What cannot be turned off
These are sent regardless of every switch. Each one either proves you hold the address, or reports a change to a credential, so silencing it would be a security problem rather than a preference. There are 14 of them.
| When | |
|---|---|
| Sign-in code | Every email sign-in |
| Step-up verification code | A guarded action outside the one hour window, when you answer with the emailed factor. Answering with an authenticator code sends nothing |
| Two factor authentication is on | Enrolment completed. Carries the number of recovery codes issued |
| Two factor authentication is off | The factor was turned off |
| A recovery code was used | A recovery code was accepted at sign in. Carries how many are left |
| Confirm your new email | You requested an email change, sent to the new address |
| Your email address was changed | The change landed, sent to the old address |
| Your account was deleted | Account deletion completed |
| CLI device approved | You approved a device from envless login |
| Workspace invitation | Someone invited your address |
| Your invitation is expiring | 24 hours before a pending invite expires |
| API key created, rotated, deactivated or deleted | Any key lifecycle change, to members who hold a keys:* permission |
| You were removed from a workspace | A member was removed |
| Product access granted or revoked | A grant on a private product changed |
Key lifecycle mail has no switch. It is filtered by permission, not by preference, so anyone whose role can create, update, rotate or delete keys is told about every key change in that workspace and cannot opt out. If that traffic is unwanted, narrow the role rather than looking for a toggle.
Saving a change
The Notifications section saves with the same Save button as Hide emails, and posts to internal/users/preferences:
{
"notifications": {
"billing": false,
"onboarding": false
}
}Only the keys you send are touched. The server merges them over what is stored, so a payload naming one switch leaves the other five as they were. Keys that are not one of the six, and values that are not booleans, are dropped before the merge rather than rejected. A payload that changes nothing answers 200 with No changes detected. and writes nothing.
The endpoint reads hideEmails and notifications together and refuses with 400 and Invalid preferences payload. only when neither is usable. A malformed hideEmails alongside a valid notifications object is ignored, not an error, and the notification change still saves.