feat: add team page with member management and invite flow

[adaam2]

Summary

Adds in-app team management to Gram — replaces the external Speakeasy team settings redirect with a native Team page and invite flow.

What changed

Team management page (/:org/:project/team)

• Member list table with remove member action
• Pending invites section with cancel/resend actions
• Invite dialog with email validation
• Sidebar link replaces the old external Speakeasy redirect

Invite acceptance via OAuth callback

• /invite?token=... page shows invite preview (org name, inviter, masked email) and "Accept invite" button
• Clicking accept redirects through the OAuth login flow with the invite token encoded in state
• The server processes invite acceptance atomically during the OAuth callback — no separate AcceptInvite API endpoint
• Token is pre-validated before granting whitelist bypass (prevents garbage/expired tokens from bypassing invite-only mode)
• Users who fail invite processing have their session revoked to prevent unauthorized access
• DevMode flag skips email match check for local development

Backend teams service (7 endpoints)

• listMembers, inviteMember, listInvites, cancelInvite, resendInvite, getInviteInfo, removeMember
• Secure random token generation (32 bytes → 64 char hex), 7-day expiry, token rotation on resend
• 5-minute resend cooldown, 50-invite/24h rate limit per org
• Duplicate invite and existing member detection

Email delivery

• Loops transactional email client (server/internal/thirdparty/loops/client.go)
• Graceful no-op when LOOPS_API_KEY is unconfigured

Database

• team_invites table with soft delete, unique constraints on pending org+email and token
• Migration in 20260129231659_team-invites.sql

Frontend changes

• AcceptInvite.tsx — standalone invite page with Gram/Speakeasy branding, status handling (expired/accepted/cancelled)
• Team.tsx — full team management page wired to SDK react-query hooks
• Auth.tsx — added /invite to unauthenticated paths, added FullPageError boundary
• app-sidebar.tsx — replaced external Speakeasy team link with in-app route
• SDK regenerated with all teams endpoints and react-query hooks

Test plan

• Server compiles and linter passes
• Team page renders current org members
• Invite dialog validates email, creates invite, shows in pending list
• Cancel and resend invite actions work
• Remove member confirmation dialog works
• /invite?token=... while logged out → redirects through OAuth login
• /invite?token=... while logged in → shows invite details, accept redirects through OAuth
• Expired/cancelled/used invite tokens show appropriate messages
• Invalid or garbage invite tokens do not bypass whitelist
• Sidebar shows Team link (no longer links to Speakeasy)

🤖 Generated with Claude Code

---

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
gram	Ready	Preview, Comment	Feb 4, 2026 6:43pm
gram-docs-redirect	Ready	Preview, Comment	Feb 4, 2026 6:43pm

[changeset-bot]

🦋 Changeset detected

Latest commit: 6a81715

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
server	Minor
dashboard	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[speakeasybot]

🚀 Preview Environment (PR #1403)

Preview URL: https://pr-1403.dev.getgram.ai

Component	Status	Details	Updated (UTC)
✅ Database	Ready	Existing database reused	2026-02-04 18:51:02.
✅ Images	Available	Container images ready	2026-02-04 18:50:44.

_{Gram Preview Bot}

[devin-ai-integration]

Devin Review found 1 new potential issue.

🟡 1 issue in files not directly in the diff

🟡 Pending invite uniqueness is case-sensitive in DB, allowing duplicate invites for same email with different casing (server/migrations/20260129231659_team-invites.sql:21-22)

The application treats invite emails as case-insensitive (e.g. GetPendingInviteByEmail matches on lower(email) = lower(@email)), but the database unique index that is supposed to prevent duplicate pending invites is case-sensitive and does not normalize casing.

Actual behavior: two concurrent requests (or requests from different clients) can create two pending invites for [email protected] and [email protected] in the same org because the unique index is on the raw email value.

Expected behavior: the DB should enforce case-insensitive uniqueness for pending invites so duplicates cannot be created even under races.

Impact: duplicated pending invites can be created and emailed, and later flows that assume a single pending invite per email/org can behave unexpectedly.

Click to expand

Where the mismatch happens

• DB constraint is case-sensitive:

  • server/migrations/20260129231659_team-invites.sql:21-22

  CREATE UNIQUE INDEX "team_invites_organization_id_email_pending_key"
    ON "team_invites" ("organization_id", "email")
    WHERE ((deleted IS FALSE) AND (status = 'pending'::text));

• App queries treat email as case-insensitive:

  • server/internal/teams/queries.sql:40-45

  WHERE organization_id = @organization_id
    AND lower(email) = lower(@email)
    AND status = 'pending'
    AND deleted IS FALSE;

How it can be triggered

1. Request A invites [email protected].
2. Request B (near-simultaneously) invites [email protected].
3. Both GetPendingInviteByEmail checks can pass (race).
4. Both inserts succeed because the unique index doesn’t consider lowercasing.

Recommendation: Enforce case-insensitive uniqueness at the DB layer, e.g. by indexing on lower(email) (and updating queries accordingly), or by using citext for email and indexing the normalized value. Ensure the unique constraint matches the application’s lower(email) semantics.

View issue and 19 additional flags in Devin Review.

[devin-ai-integration]

Devin Review found 1 new potential issue.

🟡 1 issue in files not directly in the diff

🟡 Pending invite uniqueness is case-sensitive in DB, allowing duplicate invites for same email with different casing (server/migrations/20260129231659_team-invites.sql:21-22)

The application treats invite emails as case-insensitive (e.g. GetPendingInviteByEmail matches on lower(email) = lower(@email)), but the database unique index that is supposed to prevent duplicate pending invites is case-sensitive and does not normalize casing.

Actual behavior: two concurrent requests (or requests from different clients) can create two pending invites for [email protected] and [email protected] in the same org because the unique index is on the raw email value.

Expected behavior: the DB should enforce case-insensitive uniqueness for pending invites so duplicates cannot be created even under races.

Impact: duplicated pending invites can be created and emailed, and later flows that assume a single pending invite per email/org can behave unexpectedly.

Click to expand

Where the mismatch happens

• DB constraint is case-sensitive:

  • server/migrations/20260129231659_team-invites.sql:21-22

  CREATE UNIQUE INDEX "team_invites_organization_id_email_pending_key"
    ON "team_invites" ("organization_id", "email")
    WHERE ((deleted IS FALSE) AND (status = 'pending'::text));

• App queries treat email as case-insensitive:

  • server/internal/teams/queries.sql:40-45

  WHERE organization_id = @organization_id
    AND lower(email) = lower(@email)
    AND status = 'pending'
    AND deleted IS FALSE;

How it can be triggered

1. Request A invites [email protected].
2. Request B (near-simultaneously) invites [email protected].
3. Both GetPendingInviteByEmail checks can pass (race).
4. Both inserts succeed because the unique index doesn’t consider lowercasing.

Recommendation: Enforce case-insensitive uniqueness at the DB layer, e.g. by indexing on lower(email) (and updating queries accordingly), or by using citext for email and indexing the normalized value. Ensure the unique constraint matches the application’s lower(email) semantics.

View issue and 23 additional flags in Devin Review.

[devin-ai-integration]

Devin Review found 2 new potential issues.

🟡 1 issue in files not directly in the diff

🟡 Pending invite uniqueness is case-sensitive in DB, allowing duplicate invites for same email with different casing (server/migrations/20260129231659_team-invites.sql:21-22)

The application treats invite emails as case-insensitive (e.g. GetPendingInviteByEmail matches on lower(email) = lower(@email)), but the database unique index that is supposed to prevent duplicate pending invites is case-sensitive and does not normalize casing.

Actual behavior: two concurrent requests (or requests from different clients) can create two pending invites for [email protected] and [email protected] in the same org because the unique index is on the raw email value.

Expected behavior: the DB should enforce case-insensitive uniqueness for pending invites so duplicates cannot be created even under races.

Impact: duplicated pending invites can be created and emailed, and later flows that assume a single pending invite per email/org can behave unexpectedly.

Click to expand

Where the mismatch happens

• DB constraint is case-sensitive:

  • server/migrations/20260129231659_team-invites.sql:21-22

  CREATE UNIQUE INDEX "team_invites_organization_id_email_pending_key"
    ON "team_invites" ("organization_id", "email")
    WHERE ((deleted IS FALSE) AND (status = 'pending'::text));

• App queries treat email as case-insensitive:

  • server/internal/teams/queries.sql:40-45

  WHERE organization_id = @organization_id
    AND lower(email) = lower(@email)
    AND status = 'pending'
    AND deleted IS FALSE;

How it can be triggered

1. Request A invites [email protected].
2. Request B (near-simultaneously) invites [email protected].
3. Both GetPendingInviteByEmail checks can pass (race).
4. Both inserts succeed because the unique index doesn’t consider lowercasing.

Recommendation: Enforce case-insensitive uniqueness at the DB layer, e.g. by indexing on lower(email) (and updating queries accordingly), or by using citext for email and indexing the normalized value. Ensure the unique constraint matches the application’s lower(email) semantics.

View issues and 23 additional flags in Devin Review.

[devin-ai-integration]

Devin Review found 2 new potential issues.

🟡 1 issue in files not directly in the diff

🟡 Pending invite uniqueness is case-sensitive in DB, allowing duplicate invites for same email with different casing (server/migrations/20260129231659_team-invites.sql:21-22)

The application treats invite emails as case-insensitive (e.g. GetPendingInviteByEmail matches on lower(email) = lower(@email)), but the database unique index that is supposed to prevent duplicate pending invites is case-sensitive and does not normalize casing.

Actual behavior: two concurrent requests (or requests from different clients) can create two pending invites for [email protected] and [email protected] in the same org because the unique index is on the raw email value.

Expected behavior: the DB should enforce case-insensitive uniqueness for pending invites so duplicates cannot be created even under races.

Impact: duplicated pending invites can be created and emailed, and later flows that assume a single pending invite per email/org can behave unexpectedly.

Click to expand

Where the mismatch happens

• DB constraint is case-sensitive:

  • server/migrations/20260129231659_team-invites.sql:21-22

  CREATE UNIQUE INDEX "team_invites_organization_id_email_pending_key"
    ON "team_invites" ("organization_id", "email")
    WHERE ((deleted IS FALSE) AND (status = 'pending'::text));

• App queries treat email as case-insensitive:

  • server/internal/teams/queries.sql:40-45

  WHERE organization_id = @organization_id
    AND lower(email) = lower(@email)
    AND status = 'pending'
    AND deleted IS FALSE;

How it can be triggered

1. Request A invites [email protected].
2. Request B (near-simultaneously) invites [email protected].
3. Both GetPendingInviteByEmail checks can pass (race).
4. Both inserts succeed because the unique index doesn’t consider lowercasing.

Recommendation: Enforce case-insensitive uniqueness at the DB layer, e.g. by indexing on lower(email) (and updating queries accordingly), or by using citext for email and indexing the normalized value. Ensure the unique constraint matches the application’s lower(email) semantics.

View issues and 22 additional flags in Devin Review.

[devin-ai-integration]

Devin Review found 4 new potential issues.

🟡 2 issues in files not directly in the diff

🟡 team_invites.organization_id foreign key uses ON DELETE CASCADE (can delete invites on org deletion unexpectedly) (server/migrations/20260129231659_team-invites.sql:12-15)

The new team_invites table defines organization_id with ON DELETE CASCADE.

Actual: deleting an organization row will cascade-delete all associated invites.

Expected: per repo DB guidelines, foreign keys should use ON DELETE SET NULL to avoid accidental cascading data loss; plus invite rows could be retained for audit/debugging even if an org is removed.

Click to expand

Migration:

CONSTRAINT "team_invites_organization_id_fkey" FOREIGN KEY ("organization_id")
  REFERENCES "organization_metadata" ("id") ON UPDATE NO ACTION ON DELETE CASCADE,

server/migrations/20260129231659_team-invites.sql:12-15

Recommendation: Change to ON DELETE SET NULL (and make organization_id nullable if required), or explicitly document why cascade deletion is desired here.

---

🟡 Pending invite uniqueness is case-sensitive in DB, allowing duplicate invites for same email with different casing (server/migrations/20260129231659_team-invites.sql:21-22)

The application treats invite emails as case-insensitive (e.g. GetPendingInviteByEmail matches on lower(email) = lower(@email)), but the database unique index that is supposed to prevent duplicate pending invites is case-sensitive and does not normalize casing.

Actual behavior: two concurrent requests (or requests from different clients) can create two pending invites for [email protected] and [email protected] in the same org because the unique index is on the raw email value.

Expected behavior: the DB should enforce case-insensitive uniqueness for pending invites so duplicates cannot be created even under races.

Impact: duplicated pending invites can be created and emailed, and later flows that assume a single pending invite per email/org can behave unexpectedly.

Click to expand

Where the mismatch happens

• DB constraint is case-sensitive:

  • server/migrations/20260129231659_team-invites.sql:21-22

  CREATE UNIQUE INDEX "team_invites_organization_id_email_pending_key"
    ON "team_invites" ("organization_id", "email")
    WHERE ((deleted IS FALSE) AND (status = 'pending'::text));

• App queries treat email as case-insensitive:

  • server/internal/teams/queries.sql:40-45

  WHERE organization_id = @organization_id
    AND lower(email) = lower(@email)
    AND status = 'pending'
    AND deleted IS FALSE;

How it can be triggered

1. Request A invites [email protected].
2. Request B (near-simultaneously) invites [email protected].
3. Both GetPendingInviteByEmail checks can pass (race).
4. Both inserts succeed because the unique index doesn’t consider lowercasing.

Recommendation: Enforce case-insensitive uniqueness at the DB layer, e.g. by indexing on lower(email) (and updating queries accordingly), or by using citext for email and indexing the normalized value. Ensure the unique constraint matches the application’s lower(email) semantics.

View issues and 28 additional flags in Devin Review.

[devin-ai-integration]

🔴 Invite acceptance can succeed but leave session pointing at wrong organization when UpdateSession fails

During OAuth callback invite processing, processInviteToken updates session.ActiveOrganizationID and then calls s.sessions.UpdateSession(ctx, *session) but logs and ignores any error.

Actual: if session cache update fails (e.g., redis outage), the callback handler still returns a successful redirect to /<orgSlug> with the session cookie, but the stored session may still have the old ActiveOrganizationID (or empty), leading to authorization failures or landing the user in the wrong org.

Expected: a failure to persist the updated session should fail the invite acceptance flow (or at least avoid redirecting to the invited org) so the user isn’t redirected into an org they can’t access.

Click to expand

Relevant code:

// Update session to point at the invited org.
session.ActiveOrganizationID = invite.OrganizationID
if err := s.sessions.UpdateSession(ctx, *session); err != nil {
    s.logger.ErrorContext(ctx, "failed to update session after invite accept",
        attr.SlogError(err),
    )
}

server/internal/auth/impl.go:684-690

Impact:

• User may be redirected to the invited org route but still be treated as not in that org.
• Can manifest as confusing unauthorized/forbidden errors immediately after accepting an invite.

Recommendation: Return an error (and revoke/clear the session if appropriate) when UpdateSession fails, or re-store the session and only redirect to the invited org after persistence succeeds.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 teams SDK docs list a non-existent/incorrect acceptInvite operation

The generated Teams SDK documentation includes an acceptInvite operation (operationID="acceptTeamInvite" and path /rpc/teams.acceptInvite) but there is no corresponding endpoint in the OpenAPI for this PR and no generated client function in client/sdk/src/funcs.

Actual: SDK consumers relying on docs will attempt to call an endpoint that doesn't exist (and may get runtime 404s).

Expected: Teams docs should only list operations that exist in the API spec and generated client.

Click to expand

Evidence:

• Docs claim operation exists: client/sdk/docs/sdks/teams/README.md:9-41 (acceptInvite section).
• No implementation generated (search in SDK source): no matches for acceptTeamInvite / teamsAcceptInvite in client/sdk/src.

Recommendation: Regenerate SDK docs from the correct OpenAPI, or remove the stray acceptInvite section so docs match the actual generated client/API.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[disintegrator]

remove this attribute and any associated usage of it

[simplesagar]

In the email template we use the term workspace. In gram the appropriate term is organisations and projects

[adaam2]

In the email template we use the term workspace. In gram the appropriate term is organisations and projects

I think project is the best choice