Invite and manage members

Members are managed in the dashboard, at Team. This page describes the rules each flow enforces. For the roles themselves and what each one may do, read Workspaces and members.

​

Invite somebody

Who can do this: owner or admin. You need their email address and the role you want them to hold. An invitation can offer admin, developer or viewer:

An invitation can offer admin, developer or viewer.

Owner is not on that list, because ownership moves only by transfer. Only the owner can offer admin: an admin inviting a second admin would confer no new permission but would confer persistence, and a stolen admin session must not leave a permanent administrator behind. That refusal reads Only the workspace owner can make someone an admin. You can also reserve a key for them, so they arrive with a credential waiting. The reservation takes one of the workspace’s five key slots immediately. See Create an API key. A workspace may hold up to ten pending invitations at once.

​

What the invitee sees

They get an emailed link. Clicking it lands on an invitation page that works whether or not they are signed in, and shows them which workspace they are being invited to and as what.

• The link works only for the address it was sent to.
• It is valid for seven days from when it was sent.
• Accepting it requires signing in as that address. Because a session can only exist for an address that has already been verified, accepting the invitation is itself proof of the mailbox, and no separate verification step is asked for.
• The inviter’s authority is re-checked at the moment of acceptance. An invitation sent by somebody who has since lost the right to send it does not work.

A link that matches nothing and a link that belongs to somebody else’s address answer identically. That is deliberate: anything else would let anybody holding a session discover that an invitation exists, and for whom.

​

Cancel a pending invitation

Who can do this: owner or admin, the same permission as sending one, because cancelling takes back exactly what sending gave out. Cancelling also cancels any key reservation the invitation carried, which frees the slot.

​

Change what a member may do

Who can do this: owner or admin. Two rules apply on top of the permission:

• Never to or from owner. Ownership is transferred, never granted. Use the transfer control instead.
• Only the owner makes or unmakes an admin. Only the workspace owner can make someone an admin.
• Never above your own authority. You cannot give somebody permissions you do not have yourself.

A role change never revokes a key. If you move somebody down to viewer, the keys they were accountable for keep working, and they keep answering for them until somebody changes that explicitly. Your own role is read at the moment you press the button, not when the screen loaded. If you were demoted in between, the change is refused.

​

Transfer the workspace

Who can do this: the owner, and nobody else. It is the one thing an admin cannot do. The transfer promotes the new owner and demotes you in the same write, so the workspace never has two owners and never has none. You do not stay an owner alongside them, and there is no undo other than the new owner transferring it back. Because the owner is the only role that touches money, transferring the workspace hands over the card, the buying of credit, and the ability to pause requests. Read the owner and money before you press it.

​

Remove somebody

Who can do this: owner or admin. Removal is not a single button, because taking somebody out of a workspace has consequences for keys that are still serving traffic. A kept key can also carry a rotate-by date, which is a reminder to replace it. It is a reminder and never a kill switch: a key that revoked itself on a date nobody was watching would move the outage rather than remove it. A removal that would leave the workspace with no owner is refused, and the refusal names transfer as the way through. Transfer first, then remove.

​

Refusals you may hit

Where your role does not carry the action, the answer is HTTP 403 with:

Your role in this workspace does not allow that.

You are told this rather than being shown nothing, because the screen offered the control and an unexplained absence leaves you with nothing to act on. A workspace you are not a member of answers as though it does not exist, which is a different case and deliberately indistinguishable from a workspace that really does not.

​

What is not covered here

Leaving a workspace yourself. There is no documented self-removal flow. An owner or admin removes people.

​

Next