Organisations & teams
Personal workspace, team orgs, roles, invitations.
Every SovrGPT account has a personal organisation (workspace) by default. It is private, belongs only to you, and holds all chats, API keys, connectors and quotas.
Anyone who wants to work together with others additionally creates a team organisation.
Personal org
- Created automatically at first login (slug = user hash).
- Shown in the sidebar as "Personal".
- Cannot be deleted.
- Default tier: free (models work, but fair use applies).
Creating a team org
- Sidebar → "+ New team organisation"
- Choose a slug (
acme-gmbh) — it becomes part of the URL:sovrgpt.com/orgs/acme-gmbh/... - Choose a name (
ACME GmbH). - After creation you are automatically the
owner.
Roles
| Role | Permissions |
|---|---|
owner | Everything (delete, change tier, manage members, billing). |
admin | Invite/remove members, manage connectors, revoke API keys. |
member | Create chats, use models, manage their own API keys. |
Inviting members
Sidebar → Org & members → "Invite".- Enter an e-mail address and choose a role.
- The invitee receives a magic link. After logging in they become a member.
- Invited members without a SovrGPT account are onboarded automatically.
Switching orgs
The active org is shown at the top of the sidebar. Clicking it opens the dropdown listing every org you are a member of. Selecting one switches the whole context (all chats, connectors, API keys, quotas).
What is org-scoped?
The following always belong to an org, not to a user:
- Chats & messages
- Uploaded attachments (storage bucket
attachments) - API keys
- Marketplace connectors (OAuth tokens)
- Scheduled jobs
- Usage & logs
After switching orgs you see only the chats, keys and connectors of the active org.
Visible models per org
Under Settings → Models, owners and admins decide which models can be selected in their organisation. Two modes:
| Mode | Behaviour |
|---|---|
| Show all models (default) | New models in the catalogue appear automatically. |
| Only the selected ones | New models stay hidden until they are enabled. |
Three things that often surprise people:
- It takes effect server-side, not just in the picker. A hidden model cannot
be addressed through the API either:
POST /v1/chat/completionsanswers with404 model_not_found, andGET /v1/modelsdoes not list it at all. - Running chats do not break. A chat that is already pinned to a model keeps running on it. Hiding is a rule for selection, not an emergency stop for existing conversations.
- Agents and scheduled jobs using a hidden model fall back to an allowed one automatically — a nightly cron job does not fail because of it.
The plan remains the upper bound: the org selection can only restrict, never unlock models the plan does not include.
Row-level security
We use Postgres RLS. On every table containing user data, a policy filters by org membership. Even if an SQL injection succeeded, the policy would prevent org A from seeing data belonging to org B.
Custom subdomain (enterprise)
On request, an org can be mapped to its own subdomain (acme.sovrgpt.com). This
is agreed in the contract with eNetworkers.