Skip to Content
v1.36.0 · shipped One-screen report · Looks like your app Read the changelog →
Admin consoleTeam members
Invite teammates after the first fix lands · · open live demo ↗

Teams and members

Route: /team?view=members (Team → Members; the old /organization/members link opens it)

In Mushi Mushi, teams are modeled as organizations. An organization owns projects, billing, invitations, and the member roster. Every project keeps its existing project_id, but access is granted through organization_members.

Plans

Teams are available on Studio and Enterprise.

PlanTeams
FreeSolo workspace, 1 app
BuilderSolo workspace, 3 apps
Studio5 seats (you and up to 4 teammates; pending invitations count) and 10 apps
EnterpriseTeams plus SSO and SOC 2 controls, no app limit

The product enforces this in three places:

  • The admin UI hides the invite form and shows an upgrade prompt.
  • The API returns 402 feature_not_in_plan for invitation attempts below Studio.
  • The database rejects invitation inserts with the invitations_plan_gate trigger.

Roles

RoleUse
OwnerBilling, plan changes, member management, last-owner protected
AdminInvite users, manage project settings and integrations
MemberWork in shared projects and review reports
ViewerRead-only access to shared project data

Invitation Flow

  1. An owner or admin opens Team → Members in the admin console.
  2. They invite an email with a role.
  3. Mushi Mushi creates an invitations row with a one-time token and sends a Supabase Auth invite email when possible.
  4. The invitee signs in and opens /invite/accept?token=....
  5. The accept_invitation(token) RPC verifies the email, locks the invite row, inserts the membership, and marks the invite accepted.

The accept step is atomic so double-clicks, expired tokens, and email mismatches fail cleanly.

Last updated on
TeamManage apps