Teams

Teams are how Spec0 answers who owns what. Every API is owned by a team. Every user is a member of one or more teams in their org. Every action that touches an API or a grant runs through a team's permissions.

On the dashboard

The model

Three layers, smallest to largest:

• User. A person. A user can belong to more than one organisation — their own, their employer's, a client's — and is a member of one or more teams within each. One organisation is active at a time; the organisation switcher changes which.
• Team. The ownership boundary. APIs, mocks, and grants all hang off a team.
• Org. The billing and isolation boundary. Everything you see — APIs, teams, grants — belongs to your active organisation; you never see another org's data, even one you're also a member of, unless you switch into it.

The first user to sign up creates an organisation and becomes its admin. From there, the admin invites members and creates teams. Members can be added to multiple teams; the APIs they can reach depend on which teams they're in. A user's role is per-organisation — admin in one, a regular member in another. See Access control.

What a team can do

• Own and publish APIs. Members of the team can publish new versions, edit metadata, configure governance.
• Approve grants on APIs the team owns. A consumer team requests a grant with a set of permissions on specific operations; the owning team's admin approves, trims, or rejects. See Grants.
• Depend on other teams' APIs. A team that holds approved grants sees them under /grants and receives notifications when those APIs change.
• Run mock servers scoped to the team's APIs — mock data is isolated per team. See Mock server.

How permissions are enforced

Two lines of defence — both checked on every request.

1. ABAC at the request boundary. Each endpoint declares the permission it needs (api:publish, subscription:manage, etc.); a Spring Security check resolves the caller's identity (Clerk JWT for the web app, API key for the CLI / CI / agents) to a (userId, orgId, teams[]) and rejects any mismatch.
2. Hibernate @Filter at the ORM layer. Every query against a multi-tenant entity automatically carries WHERE org_id = :orgId — see ADR-0010. A bug in application code that forgot to filter by org couldn't leak data because the database itself wouldn't return it.

Together these mean cross-org leaks are structurally impossible: the org-id filter is a SQL WHERE clause that lives below the application logic, not a check the application has to remember.

Inviting and removing

From the UI: Settings → Members → Invite (or Teams → [team] → Members → Invite). The invitee gets a Spec0 email with an accept link. It works whether they're new to Spec0 or already have an account in another organisation — accepting adds your organisation to the ones they belong to; they keep their existing one and can switch between them. New users land in the org and team on their first sign-in.

Pending invitations are manageable from Settings → Members: resend one that expired or got lost, or cancel it to free the email up to be invited again. Removing an existing member revokes their access immediately — the next API call from a removed member fails ABAC. See Managing members for the full flow.

For non-human callers (CI runners, CLI bots, AI agents) use Settings → API keys and create a key tied to a team rather than inviting a synthetic user. The key carries the same team membership a real user would have.

API keys and tokens

There is no separate credential system for MCP, REST, or CLI. The same key works across all three. See the agents page for the wiring.

Where to go next

• APIs — what teams own and govern.
• Grants — what teams approve and consume.
• Events — team-scoped notifications.
• spec0 auth login — wiring a CLI install into a team.