Invite members
Adding a teammate takes one link. An admin creates the invite, you send them the URL, and they join the organization as soon as they open it while signed in and choose Accept invite.
Before you start
| Requirement | Why |
|---|---|
| You are an admin of the active organization | Invites are an admin-only action |
| The active workspace is not your personal one | Personal workspaces cannot have members |
If the switcher at the top of the sidebar says Personal, create an organization first — see Switching organizations.
Create an invite
- Open Team in the sidebar.
- Choose Invite.
- Enter the teammate's email address.
- Pick a role: Member — deploy & use the API or Admin — full access.
- Choose Create invite.
Superheat returns a link:
https://cloud.superheat.xyz/join?token=<token>
Copy it before you close the dialog. The token is shown exactly once and cannot be retrieved later. If you lose it, revoke the invite and create a new one.
The invite is bound to the email address you typed: only an account signed in as that address can accept it. Anyone else who opens the link gets Invite not found, even with a perfectly valid token.
That is a real restriction, not a formality — but the token still travels in a URL, where
it leaks through pasted links and Referer headers. Send it directly to the person rather
than to a shared channel, and revoke it if it goes somewhere it should not.
How your teammate accepts
There are two paths, and both end with the same membership.
| Path | What they do |
|---|---|
| The link | Sign in, open /join?token=…, choose Accept invite |
| In the console | Sign in with the invited email address, then accept the banner on the dashboard that reads "You've been invited to …" |
Both paths require signing in as the invited address; the banner is a convenience, not a second way in.
Accepting switches their active workspace to your organization and drops them on the dashboard. If they do not have an account yet, they create one first with the same passwordless flow — see Create an account.
If something goes wrong:
| Message | What happened |
|---|---|
| This invite has already been used | Each invite is single-use. Create another. |
| This invite has expired | Invites last 7 days from creation. |
| Invite not found | The invite was revoked, the token is wrong or truncated — or you are signed in as a different email address than the one invited. Sign out and sign back in as the invited address. |
| Missing invite token | The URL was opened without its ?token= part. Copy the whole link. |
Pending invites
The Team page lists every invite that has not yet been accepted and has not expired, with the role and the expiry date. Admins see this list; members do not.
- Revoke deletes the invite. The link stops working immediately.
- An invite drops off the list once it is accepted, revoked, or 7 days old.
From the API
Creating an invite is an admin action, so it requires a session token. An shk_ API key is rejected on every admin endpoint, even when its creator is an admin.
curl -X POST "$SUPERHEAT_API/v1/orgs/current/invites" \
-H "Authorization: Bearer $SESSION_TOKEN" \
-H "X-Org-Id: $ORG_ID" \
-H "Content-Type: application/json" \
-d '{"email": "teammate@company.com", "role": "member"}'
{
"invite": {
"id": "0f1c9e2a-8a1e-4a1b-9a52-2f3f0b6f6a11",
"email": "teammate@company.com",
"role": "member",
"created_at": "2026-03-04T10:12:00Z",
"expires_at": "2026-03-11T10:12:00Z"
},
"invite_url": "https://cloud.superheat.xyz/join?token=…"
}
invite_url is the only place the token appears.
| Endpoint | Who can call it |
|---|---|
POST /v1/orgs/current/invites | Admins, session token only |
GET /v1/orgs/current/invites | Admins — unaccepted, unexpired invites |
DELETE /v1/orgs/current/invites/{invite_id} | Admins — revoke |
GET /v1/orgs/invites/pending | Any signed-in user — invites addressed to their email |
POST /v1/orgs/invites/{invite_id}/accept | The invited user, accepting one of those |
POST /v1/orgs/invites/accept | Any signed-in user, body {"token": "…"} |
What a new member gets on day one
They immediately share the organization's credit balance, its instances, its templates, its API keys, and its usage log. They do not share your SSH keys — those stay on each user's own account. See Roles and permissions for exactly what a member may do, and Switching organizations for what stays behind the boundary.