Switching organizations
One account can belong to several workspaces at once. The switcher at the top of the sidebar decides which one you are working in — and everything you see, deploy, and spend belongs to that one.
The workspaces you belong to
| Workspace | Where it comes from | Your role |
|---|---|---|
| Personal | Created for you at first sign-in | Admin, and the only member |
| An organization you created | The Create organization… entry in the switcher | Admin |
| An organization you joined | An invite link or an accepted invite | Whatever the invite granted |
The switcher shows the active workspace's name — Personal for your personal one — with your role in that organization underneath, so you can tell at a glance whether you can add credits here. The personal workspace reads Personal workspace in that spot instead, because you are always its only member.
Switching
Pick another workspace from the switcher. Three things happen:
- The console drops every cached page of data and refetches it for the new organization.
- Every subsequent API request carries that organization's id in the
X-Org-Idheader. Switching back to Personal clears the header instead — an absentX-Org-Idalready means your personal workspace. - The selection is saved in that browser, so you land back in the same workspace next time.
You stay signed in as the same user throughout — switching changes context, not identity. The selection is per browser: a second device starts on your personal workspace until you switch there too.
An instance bills the balance of whatever workspace is active when you choose Deploy instance, and it cannot be moved afterward. Deploying into your personal workspace by accident spends your own credits rather than the team's.
Creating an organization
Open the switcher, choose Create organization…, and give it a name of up to 64 characters. You become its admin and the console switches you into it immediately. It starts with a zero balance, no instances, and no templates of its own. Add credits, then invite your teammates.
What belongs to the organization, and what belongs to you
| Thing | Scoped to | Crosses workspaces? |
|---|---|---|
| Credit balance and transactions | Organization | No |
| Instances | Organization | No |
| API keys | Organization | No |
| Templates you create | Organization | Only if you set one to public |
| Usage log | Organization | No |
| Members and roles | Organization | No |
| SSH keys | User | Yes — the same list everywhere |
| Sign-in methods, two-factor, passkeys | User | Yes |
Templates are the one partial exception. A template is visible from a workspace when it is a system template curated by Superheat, when its visibility is public, or when the active organization owns it. Duplicating one you do not own produces a private copy owned by the active organization, with any secret environment values and private registry credentials blanked.
Credits never cross
Each organization buys and spends its own credits. There is no transfer between workspaces, no shared pool, and no borrowing: a personal workspace with $200 does nothing for an organization sitting at zero.
The automatic protections are per organization too. When one organization's balance hits zero, its running instances are stopped; at −$5, its instances are destroyed. Another workspace being funded does not save them. See How billing works.
Only an admin of that specific organization can top it up. Being an admin elsewhere does not help.
Instances never cross
The instances list, the deploy page, and every instance endpoint return only the active organization's machines. You cannot see, start, stop, or destroy an instance that belongs to a workspace you are not currently in — even if you are a member of both. Switch first.
Spend is attributed the same way: an instance charges the organization that deployed it for its whole life, no matter who later stops or destroys it.
API keys never cross
An shk_ key is minted inside one organization and stays pinned to it. It carries member-level access to that organization alone.
- Sending a key with an
X-Org-Idheader for a different organization returns403 ORG_MISMATCH. - To automate against two organizations, mint one key in each and select between them in your own code.
- A key keeps working on its organization regardless of the workspace its creator is currently viewing in the console.
See API keys.
SSH keys follow you
SSH keys are the exception: they live on your user account, not on any organization. Add a key once and it appears in every workspace you belong to, including ones you join later. Removing a key removes it everywhere.
At deploy time you can only select a key from your own account — a teammate's keys are not offered, and the API rejects a key id that is not yours. An instance is provisioned with the single key its deployer chose, so teammates do not automatically get shell access to a machine someone else deployed. They can still see it, read its logs, stop it, and destroy it from the console.
See Add a key.
Selecting an organization from the API
The X-Org-Id header selects the workspace for org-scoped endpoints. Omit it and the request uses your personal workspace.
curl "$SUPERHEAT_API/v1/instances" \
-H "Authorization: Bearer $SESSION_TOKEN" \
-H "X-Org-Id: $ORG_ID"
| Call | What it gives you |
|---|---|
GET /v1/orgs | Every workspace you belong to, with your role and its balance |
GET /v1/orgs/current | The active workspace, its balance, your role, and its member list |
Two errors are worth recognizing: 403 NOT_A_MEMBER means the header names an organization you do not belong to, and 400 INVALID_ORG_ID means the header is not a valid id.
Leaving an organization
There is no self-service leave. Ask an admin of that organization to remove you from the Team page; the workspace then disappears from your switcher. If you are its last admin, promote someone else first. Your personal workspace is permanent and cannot be left.