Members & roles

For agents: list_members(org="acme") (org:read) lists who has access. Adding, re-roling and removing members is human-only: a signed-in admin does it in Settings → Members. An API token, including an MCP agent's, gets 403. Granting access outlives the credential that granted it, so a leaked token could otherwise add its holder as an admin and survive being revoked. The person must already have a Bugwatch account; there is no invitation email yet, so tell them to sign up first.

Roles

Roles apply to dashboard sessions; API tokens carry their own scope list (Tokens & scopes). The owner is the person who created the organization. Owners cannot be removed or re-roled through the members API, so an organization can never be orphaned.

Viewers can see every issue, event, trace, release, and alert rule but cannot change anything. The rule behind it: never block someone from seeing production errors because of a seat count.

Adding members

curl -sS https://api.bugwatch.io/v1/orgs/acme/members -H 'Authorization: Bearer bwt_<admin>' \
  -H 'content-type: application/json' -d '{"email":"priya@example.com","role":"member"}'

• role is admin, member, or viewer.
• 404 if no account exists for that email — they sign up (password, Google, GitHub, Microsoft, or magic link) and you retry. Re-adding an existing member updates their role.
• 402 when the plan's billable seats are used up: Free 3, Starter 15, Team 40, Business 100, Scale 250. The response includes viewersUnlimited: true — add them as a viewer or upgrade.

Removing members

DELETE /v1/orgs/{org}/members/{userId} — the user id is in list_members. Removing somebody severs the connection in both directions, in one step:

What they lose. Their sessions lose access on the next request, and every API token they personally created in this organization is deleted with the membership. Organization-level automation tokens (created without a user) are organization assets and are left alone, so removing a person never stops your CI ingesting.

What stops reaching them. Every phone they registered in this organization is revoked and its push credentials destroyed, and their mobile channel is deleted and detached from any service, monitor or alert rule that was paging through it. A page must not keep arriving on the lock screen of somebody who has left.

What stops depending on them. They are taken off every on-call rotation and override in this organization. This is the part that needs your attention: it is the right thing to do — a rotation entry for somebody who cannot be paged is worse than an honest gap — but it leaves shifts with nobody on them. The response says exactly what happened so you can fill the gap:

{
  "ok": true,
  "offboarding": {
    "devicesRevoked": 2,
    "channelsDeleted": 1,
    "detachedFrom": 3,
    "schedulesAffected": ["Primary", "Weekend"],
    "overridesRemoved": 1
  }
}

schedulesAffected names the schedules that just lost a person. Check each one's coverage before you close the tab.

Other organizations are untouched: someone removed here keeps their phones, tokens and rotations everywhere else they still work.

Multiple organizations

A user can belong to several organizations with different roles; GET /auth/me and whoami list them. Each organization has its own plan, tokens, channels, and releases. Creating another organization after sign-in: POST /auth/orgs {"name", "slug"}.