Team & roles

A workspace (organization) groups your team's Studio accounts and all of its projects. Every member can open every project in the workspace. Each member's role, admin or developer, decides what they can change.

Workspaces

• Signing up creates a workspace, and you are its first admin. Admins rename it in Settings → Workspace.
• Each Studio account belongs to exactly one workspace.
• Projects belong to the workspace, not to the person who created them. There is no per-project membership: every member sees every project.
• Workspace members are Studio accounts. Your app's end users are a separate system. See Authentication.

Roles

The API enforces the admin-only actions, returning 403 with the required role. Studio also hides admin-only controls from developers. Billing details are in Plans & billing.

Two other rules apply on top of roles:

• Project creator only: the Tables and Auth pages (browsing and editing rows, RLS and policies), and SQL or migrations run from the CLI or MCP server, work only for the member who created the project, whatever their role. Other members get 403 This operation is restricted to the project owner and can use the Studio SQL editor instead.
• Plans: the whole workspace shares one plan, the highest plan held by any of its admins. See Plans & billing.

Role changes take effect on the member's next request. They don't need to sign in again.

Invite a member

1. Open Members in the top navigation and click Invite member (admins only).
2. Enter their email and choose Developer (the default) or Admin.
3. They get an email with a link to /accept-invitation/<token>. There they set their name and a password, and they are signed straight into your workspace with the chosen role.

• Through the API (POST /api/admin/invitations), role must be admin or developer. Any other value returns 400.
• The new member's password must meet the workspace's minimum password length and the platform rules below.
• Invitations expire after 7 days and can be used once.
• You can't invite an email that already has an OrbitNest account, because an account can only belong to one workspace.
• Only one pending invitation per email is allowed. Pending invitations can't be listed or withdrawn. Wait for one to expire before sending another.
• Admins can send up to 10 invitations per hour.
• If the invitation email can't be sent, the invitation is discarded and you get an error, so you can try again.

Change a member's role

On Members, open the member's menu and choose Make Admin or Change to Developer.

A workspace always keeps at least one admin. Demoting the last admin is refused until you promote someone else.

Deactivate or activate a member

On Members, open the member's menu and choose Deactivate or Activate. The API route is PATCH /api/admin/admins/:id/active with { "is_active": false } or true (admins only).

• Deactivating signs the member out of every session. They can't sign in again until an admin reactivates them.
• Their account, projects and settings are kept.
• You can only change members of your own workspace.
• You can't deactivate yourself, a super admin, or the last active admin. These return 403.

Remove a member

On Members, open the member's menu and choose Delete.

• This permanently deletes the member's Studio account and signs them out everywhere. Their passkeys, linked sign-in providers and the invitations they sent are deleted with it.
• Projects they created stay in the workspace. Because the Tables and Auth pages are limited to a project's creator, those pages, and CLI or MCP SQL, stop working for the removed member's projects. The Studio SQL editor still works.
• You can't delete yourself from this list. The last admin can't be removed while other members remain.

Require two-factor authentication

Admins can turn on Require two-factor authentication for all members in Settings → Security. The API enforces it:

• A member without a verified authenticator app gets 403 with code MFA_ENROLLMENT_REQUIRED on every request, and Studio sends them to the two-factor setup screen.
• These still work while they set up: signing out, reading their profile, the two-factor and passkey setup endpoints, reading the workspace, and the Support inbox.
• Only an authenticator app counts. Passkeys don't satisfy the policy.
• The policy also applies to the CLI and MCP server, which sign in with Studio accounts, and to Studio admin tokens used to invoke edge functions.
• Super admins are exempt.

You can only turn the policy on once you have an authenticator app on your own account. Otherwise the request returns 400 with code MFA_REQUIRED_TO_ENABLE_POLICY.

Each member manages their own sign-in methods in Settings → Account: profile, passkeys, linked Google, GitHub or Apple accounts, and two-factor authentication with recovery codes.

Account changes

• Change your email: in Settings → Account, enter the new email and your current password. Studio emails a code to the new address, and the change takes effect once you enter it. Every session is then signed out. Over the API, send the new email with current_password (PATCH /api/admin/admins/:id, which returns pending_email), then the code to POST /api/admin/admins/:id/email/verify { "code": "…" }.
  • A wrong or missing password returns 403, an email another account uses returns 409, and a second request within a minute returns 429.
  • The code expires after 10 minutes, and 5 wrong codes invalidate it.
  • Accounts that sign in only with Google, GitHub or Apple can't change their email here.
• Change your password: PATCH /api/admin/admins/:id/password needs current_password. Every session is signed out after the change.

Security settings

Settings → Security holds the workspace's security policy. Each workspace has its own settings. Every member can read them (GET /api/settings/security). Only admins can change them.

To save changes, an admin requests a 6-digit code, which is emailed to them and is valid for 10 minutes (POST /api/settings/security/step-up), then sends it as step_up_code with the new values (PUT /api/settings/security). After 5 wrong codes, the codes are invalidated and you must request a new one.

Values outside these ranges, and unknown fields, return 400. The settings apply only to Studio accounts in the workspace, not to your app's end users.