API reference
Members
Reading the workspace roster. Read-only, deliberately.
Scope: members:read
GET /api/v1/users/
GET /api/v1/organizations/{slug}/members/
GET /api/v1/comments/user-search/?q=danaUse these to resolve a name or email to the numeric id that assignee,
memberships and mention payloads expect.
There is no members:write
Adding people to the workspace, removing them, and changing their roles are not on the published surface, and no scope reaches them.
Membership management is exactly how an automation would escalate its own reach: a token that can grant a role can grant itself one. So it stays a human action, taken by a person who is accountable for it.
If your provisioning flow needs to add people, do it through the app or through SSO group mapping, not through a token.
Endpoints
| Method | Path | Scope |
|---|---|---|
GET | /api/v1/comments/user-search/ | members:read |
GET | /api/v1/organizations/{slug}/members/ | members:read |
GET | /api/v1/users/ | members:read |