# Team and roles Source: https://molted.email/docs/team Invite people to your workspace by email, give each one a role, change or remove it, and hand the workspace to someone else. A workspace can have more than one person in it. You invite someone by email, pick their role, and they join by opening the link in that email. Every plan allows as many people as you like. There are no seat limits and nobody is counted or charged per person. > **Note:** Team invites are being rolled out and may not be switched on for your workspace yet. Until they are, Settings has no **People** section and invite links don't open. ## The four roles Each person in a workspace has exactly one role. From lowest to highest: | Role | What it may do | | - | - | | `viewer` | Read everything. Change nothing, and hold no API keys. | | `member` | The day-to-day work. Decide the needs-you cards, release or reject held mail, reply, and work with threads, labels, templates, journeys, lists, segments and contacts. Changes that make things safer, such as pausing sending. Their own API keys, for specific mailboxes only. | | `admin` | Everything a member does, plus the people in the workspace (except the owner), everyone's API keys, workspace, mailbox and sender settings, domains, webhooks, and every change that loosens a safety control. | | `owner` | One per workspace. Everything, plus billing, deleting the workspace and transferring ownership. | The full list per role is under [Role required](https://molted.email/docs/errors.md#role-required), and [Mailboxes](https://molted.email/docs/mailboxes.md#workspace-roles) covers what each role may do with a mailbox. When your role doesn't cover something, Molted answers `403 role_required` and says which role it needs. API keys don't have a role of their own. A key acts with the current role of the person who created it, so a key never outranks its creator. See [Keys and workspace roles](https://molted.email/docs/api-keys.md#keys-and-workspace-roles). ## Inviting someone Open **Settings > People** in the portal. Everyone in the workspace sees this list, with each person's name, email address, role and the date they joined, plus the invites still waiting. Only an admin or the owner can invite people, change roles or remove anyone. To invite, type the person's email address, pick **admin**, **member** or **viewer**, and press **Send invite**. Nobody can be invited as owner. A workspace gets a new owner only when the current one [transfers ownership](#transferring-ownership). Molted emails the person a link. The link works once and for 7 days. While it is waiting you can **Revoke** it, which kills the link at once, or **Resend** it. Resending emails a new link, makes the old one stop working and starts the 7 days again. An address has at most one waiting invite, so inviting the same address twice asks you to resend or revoke the first one instead. An invite also stops working if the person who sent it can no longer invite people, for example because they were made a member or left. The link then says the invite isn't valid anymore, just as for a revoked one. Whoever resends an invite becomes the person it is from. The invite email always has the same subject line. Your name and the workspace's name appear in its text only when they read as plain names. A name with a phone number, a web address or an email address in it, or with symbols other than `.`, `'`, `&` and `-`, is left out, and the email says "A workspace admin" or "a workspace" instead. A few addresses are refused when you invite: - the address of someone already in the workspace (`already_member`) - an address with a waiting invite (`invite_pending`) - an address Molted itself receives mail for, such as one of your mailboxes (`email_not_allowed`), since an agent could read the link there - an address that isn't one plain email address (`invalid_email`), see below ### How addresses are matched Case doesn't count. `Ana@Example.com` and `ana@example.com` are the same address. Everything else counts. `ana+work@example.com` and `a.na@example.com` are different addresses from `ana@example.com`, so invite the exact address the person signs in with. Addresses with lookalike, accented or invisible characters are refused when you invite, rather than quietly converted. A Cyrillic `а` that looks like a Latin `a`, a zero-width space or a fullwidth `@` makes it a different address, and Molted won't send an invite to one. ### Limits on invite emails A workspace sends at most 50 invite emails in any 24 hours, and one person sends at most 100 across all their workspaces. Resends count. These limits are there to stop the invite email being used for spam. They limit emails, not members, and a workspace can grow past 50 people over a few days. Over a limit, Molted answers `429 invite_rate_limited` with the limit it hit and how long to wait. An invite email is an email your workspace sends, so it follows the same rules as any other: - Your own email address must be verified first (`email_verification_required`). - The workspace must be able to send. Inviting is refused while it is suspended (`workspace_suspended`), before a plan is chosen (`trial_not_activated`), after its plan ended (`subscription_expired`), or while sending from Free workspaces is paused (`free_sends_paused`). - Each invite email counts toward the workspace's send limits, and a limit that is used up refuses the invite with `429`. ## Accepting an invite The link opens a page that says which workspace it is for, who invited you and the role you'll have. **If you're new to Molted**, sign up on that page. The email field is filled in with the invited address and can't be changed. You choose your password there, and the address counts as verified straight away, because the link only went to that inbox. This works even while public sign-ups are closed. An account made this way gets no workspace of its own, only the one it was invited to. **If you already have an account**, sign in with exactly the invited address and accept. That address must be verified already. Signed in as anyone else, you're told the invite is for another address (`invite_email_mismatch`), and you can sign out and sign in as the invited one. Once you accept, the workspace is added to the workspace switcher in the top bar and the portal opens it. Your other workspaces stay as they were. A link that was revoked, replaced by a resend, already used or past its 7 days doesn't work. Ask the person who invited you for a new one. ## Changing a role An admin or the owner picks a new role for anyone but the owner. It applies on that person's very next request, and so does every API key they created, since a key acts with its creator's role. When the change lowers someone's role, the dialog lists the keys that will lose rights. Nothing is revoked or reminted. The keys simply act with the lower role from then on. ## Removing someone, or leaving An admin or the owner can remove anyone but the owner. Removing a person revokes every API key they created in that workspace, and every key those keys minted, in the same step. The dialog lists those keys by name before you confirm. Their own account and their other workspaces aren't touched. Anyone but the owner can also leave a workspace with **Leave workspace** on their own row. Leaving revokes your keys there in the same way, and someone who manages people can invite you back later. ## The owner Nobody removes or demotes the owner, or revokes a key the owner created. The owner can't simply leave either, because a workspace always has exactly one owner. ### Transferring ownership The owner hands the workspace to another person with **Make owner** on their row. The new owner gets the workspace, its plan and its billing. The old owner becomes an admin, and only the new owner can give it back. Transferring needs a fresh sign-in. If your last password sign-in was more than 10 minutes ago, the portal asks you to sign in again first. Ownership always goes to a person in the workspace, never to the agent's account. ## The agent's account In a workspace an agent created, the agent's own account is one of the rows in the list, marked **Agent's account**. Once a person has claimed the workspace, it is an admin like any other row. You can change its role or remove it, and removing it revokes any keys it still holds there. It can't be made the owner. ## People, not agents Inviting, roles and removal are for people in the portal. There is no agent API route, MCP tool or CLI command for them, and a session an agent holds is refused. An agent joins a workspace with an API key instead, through [adoption](https://molted.email/docs/adoption.md) or a key a person creates for it in **Settings > Access** (see [Managing API keys](https://molted.email/docs/api-keys.md)). ## Routes These are the portal's own routes, called with a person's session cookie from the portal. They are listed for completeness, not for agents. | Method | Path | What it does | | - | - | - | | `GET` | `/v1/me/members` | The people in the workspace and its waiting invites | | `POST` | `/v1/me/members/invites` | Invite an address (`email`, `role`) | | `POST` | `/v1/me/members/invites/:id/resend` | Send a waiting invite again with a new link | | `DELETE` | `/v1/me/members/invites/:id` | Revoke a waiting invite | | `PATCH` | `/v1/me/members/:userId` | Change a person's role (`role`) | | `DELETE` | `/v1/me/members/:userId` | Remove a person, or leave when it's you | | `POST` | `/v1/me/members/transfer-ownership` | Make another person the owner (`userId`) | | `GET` | `/v1/invites/:token` | What an invite link is for, without signing in | | `POST` | `/v1/invites/:token/accept` | Accept an invite as the signed-in person | The error codes these return are listed under [Team and invite errors](https://molted.email/docs/errors.md#team-and-invite-errors).