Members and Teams

​

Organizations, teams and projects

An organization is the top level: it holds the members, the seats, the billing plan and the organization-wide settings. A team groups projects and the people who work on them. A project is where your traces, evaluations, prompts, datasets and API keys live. Every member has one organization role. Below the organization, access comes from role bindings: a person on a team holds that role on every project in the team, and a project-level binding adds access on one project without removing the team role. A binding at the organization scope, which is what an organization Admin holds, applies to every team and project. People joining through SSO can belong to the organization before they have team access. They see a waiting page until an administrator assigns access or the identity provider syncs a mapped group. Personal workspaces contain one personal team and project, listed under My Workspace and hidden from the team pickers. An SSO arrival waiting for team access does not receive a personal workspace automatically. Also check: Access Control (RBAC) for what each role can do.

​

Members

Settings > Directory > People lists every member with their organization role and their access. Opening the page needs organization:manage. Each row shows the name, the email, a Lite Member or Developer badge when the member is on one of those seats, a Disabled badge when access is switched off, and the Access column: one badge per role binding, as role on scope, with via <group> when the binding comes from a group. Click a row to open the member dialog:

• Organization role: Admin, Member, Lite Member or Developer. You cannot change your own role.
• Access: the team and project bindings. Add a row with a role, a scope type (organization, team or project) and the team or project. Remove a row to revoke it. A Developer has no rows to add: the seat works in its own project only.
• Group access: the bindings inherited from groups, read only.

The seat panel above the table shows Team Members and Lite Members in use against the plan limits, and Developers as a plain count, because Developer seats have no limit. Each member manages their own sign-in methods at Settings > Security: passkeys, linked accounts and their password. An administrator cannot change another member’s sign-in methods there.

​

Invite people

Click Invite people. Enter one or more email addresses separated by commas, spaces or semicolons. Under Seat, choose the seat the whole batch gets: Member, Lite Member or Developer. Each option says in a line what that seat can do, and the (i) next to Lite Member and Developer opens the full explanation. Under Team Assignments, add each team the person joins with the role on that team: Admin, Member, Viewer or a custom role. A Lite Member can only be assigned as Viewer. A Developer joins no team, so the section disappears when that seat is chosen. The drawer warns when a Lite Member invite has no team, because a Lite Member with no team sees no project. Click Send invites. When the deployment has no email provider, the button reads Create invites and you copy the invite link from the row menu instead. An invite link has the form https://app.langwatch.ai/invite/accept?inviteCode=... and works for 14 days. Resend invitation issues a new 14-day link, and Revoke cancels it. Pending invites are listed under the members table with their status: Invited, Expired, Revoked, Accepted or Awaiting payment. An invite for a full seat over the plan limit opens the seat purchase dialog or the upgrade dialog before it is sent.

​

Let colleagues join by domain

Open Settings > Authentication, then find Organization policies. The Joining your organization card controls people who do not use your identity provider: Under the door setting, Seat for people who join decides what a person admitted without an invitation lands on: Member (the default, a full seat that can be added to shared teams and projects) or Developer (a project of their own, with access to no shared team or project). The same choice applies to people your identity provider admits. Invitations always name their own seat and ignore this setting. Somebody who signs up from the terminal, by running langwatch login and creating their account on the page it opens, lands on a Developer seat whichever option is chosen here, both when you approve their request and when the door is automatic. The pending requests list shows the seat each request will land on. Raising them to a Member seat afterwards is done from the member dialog, as for anyone else. When a person reaches the welcome screen with an invitation already waiting on their verified address, accepting that invitation is offered first and asking to join is not. The seat is the one the invitation names. The Account lockout and Session limits cards in the same section apply to password sign-in for the organization. They remain available when you stop using single sign-on. Changing a policy requires organization:manage.

​

Lite Members

A Lite Member is a read-only seat, counted apart from full seats. On a team or a project a Lite Member can read traces, analytics, evaluations, datasets, prompts, workflows, experiments and scenarios, and can create and update annotations. A Lite Member cannot see costs, the LangWatch AI Gateway pages or the audit log, cannot change anything else, and has the same limits over the API and MCP. In the settings pages a Lite Member can only hold the Viewer role.

​

Developers

A Developer is a seat for somebody who needs their own place to work and no access to the shared projects: a developer sending traces from Claude Code or another coding agent, for example. A Developer gets a personal project and everything a member can do inside it: send traces from the CLI, run queries and evaluations, manage its keys. A Developer cannot open, be invited to, or be added to any shared team or project, and cannot be given access through a group either. The product switcher offers a Developer the Me workspace only: the Gateway and Governance products are organisation-wide, so a Developer cannot open them, by the switcher or by address, and never sees the organisation’s gateway keys. Developers are counted on the seat panel and never limited by the plan. Moving a member to a Developer seat removes their bindings on every shared team, shared project and the organization, and records each removal in the audit log. Their personal project, its traces and their API keys stay. A key that pointed at a shared project stops working on its own, because a key can never do more than its owner can. Moving a Developer to a Member seat grants no team access on its own; add teams afterwards. The CLI honours the seat too: langwatch login offers a Developer their personal project only and refuses a shared one, and langwatch instrument <tool> --project cannot pin a coding agent to a shared project. A person who joins the organization by domain after signing up from langwatch login lands on this seat regardless of the Seat for people who join setting (see Let colleagues join by domain).

​

Teams

Settings > Directory > Teams & projects shows every team with its projects and members. Click New team to create one; you are added as its Admin. The team card shows the members with their team role, which you can change in place, and an X to remove the member from the team. Members that come from a group are read only and show via <group>. Add to team adds an organization member with a role on this team, and so on every project in it. Under each project, Add person to this project gives a role on that project only. For someone already on the team, the page marks the row override and shows their team role next to it; the project role adds to the team role, it does not take permissions away. Remove the project role to leave only the team role. Click Edit on a team to open its page: rename it (the slug is read only), edit the members, add or archive projects. Archive this team hides the team and all its projects; contact support to restore it. A team keeps at least one Admin: removing the last one is refused.

​

Remove access

Deleting a member does not delete the traces, prompts or other work they created.

​

API

The Members API lists members and their access, updates and removes a member, and the Invites API creates, lists and revokes invites, so you can run on-boarding and off-boarding from your own tooling. Every member and invite change is written to the Audit Log.