Organisations
Belong to more than one organisation, switch the active one in a click, and understand how the active org scopes everything you see.
An organisation is Spec0's billing and isolation boundary — every API, team, mock, and subscription lives inside one. A user can belong to more than one organisation, and one of them is active at a time. The active organisation is the lens for everything you do: the APIs you browse, the teams you're on, the members you manage, and the role your request is evaluated against all come from the org you're currently in.
You can be in more than one org
You might have your own organisation, be a member of your employer's, and be invited into a client's. Each is a separate, fully isolated tenant — you never see one org's data while acting in another, even though you're a member of both. Your role is per-organisation: you can be an admin in one and a plain member in another.
New accounts start with a single organisation of their own (you name it on first run). You gain additional ones by accepting an invitation to someone else's org — accepting adds the org to your list without disturbing the one you already had.
Switching the active org
The organisation switcher sits next to the Spec0 wordmark at the top of the dashboard. Open it to see every organisation you belong to, with the active one marked, and pick another to switch into. The whole app re-resolves to the org you chose — your APIs, teams, members, and subscriptions all reflect the new active org.
If you only belong to one organisation, the switcher shows it as a static label — there's nothing to switch between yet.
The active org is per user, server-side — switching changes what your dashboard session resolves to. It does not change what a CLI or CI token sees: a token is bound to the organisation it was issued in and always operates there, regardless of where your dashboard happens to be pointed. See API keys and tokens.
How the active org scopes a request
Every authenticated request resolves to an (userId, orgId, teams[]) identity, and orgId is your active organisation (or, for a token, the org the token belongs to). From there:
- Isolation. A database-level filter scopes every query to that org — cross-org reads return nothing, structurally. See ADR-0010 and Access control.
- Roles. Only the roles you hold in that org apply. Switching organisations switches the permissions in effect.
Where to go next
- Members — invite people into an org, and how accepting an invite adds an org.
- Teams — the ownership boundary inside an organisation.
- Access control — how per-org roles turn into allow/deny decisions.