Skip to content

Roles are assigned per workspace (a workspace is called a tenant in the API, hence the --tenant-id flag below). Assigning a role is a management-plane operation against Bridge, not something @nebulr-group/bridge-express exposes an API for; there’s no bridge.assignRole(...) call in this package. Your Express backend’s job is to read the role off a verified request (see Getting the user token) and enforce it (see How roles & privileges work); assignment itself happens via the CLI, Control Center (your admin dashboard at app.thebridge.dev), or a frontend Bridge SDK’s drop-in team-management UI.

bridge user invite --email jane@example.com --role SUPPORT --tenant-id <tenantId>

--tenant-id can be omitted if you’ve set the BRIDGE_TENANT_ID environment variable. --role can be omitted too; the user gets whichever role is marked isDefault for your app.

bridge user update --user-id <userId> --role ADMIN --tenant-id <tenantId>

If your product needs an in-app “change this user’s role” flow

Section titled “If your product needs an in-app “change this user’s role” flow”

That flow lives in your frontend, not your Express backend: a frontend Bridge SDK ships a drop-in team-management component that calls Bridge directly on the signed-in admin’s behalf, letting workspace admins invite users and change roles without touching the CLI. Your Express app doesn’t need to (and today can’t) proxy that call itself: bridge-express only verifies tokens and reads their claims; it does not wrap Bridge’s role/user management endpoints.

Handle the one business rule that surfaces as an error either way. See The owner role for what happens when someone tries to demote a workspace’s last OWNER.