Skip to main content
A member is an active human in your organization. They have a profile (name, avatar) and a single role that determines what they can do. The member id is stable for the lifetime of that membership — keep it as the foreign key in any external system that mirrors your team.
This endpoint returns only active members. Pending invitations live under /team/invitations. Removed members are never returned — and once removed, a GET, PATCH, or DELETE against that member id returns 404, as if it never existed in your org.

​
The member object

​
List members

cURL
Returns every active member inside the standard list envelope. Membership rolls are bounded, so the full set is returned in one response.

​
Get a member

cURL

​
Change role

PATCH /team/members/{id} with the target role_id. The change fires member.role_changed and is reflected in the response. The role_id must be one of your organization’s roles — a role id from another org (or a nonexistent one) is rejected. The owner role is the one exception you can’t assign (see below).
cURL
Ownership is not transferable through the API. Promoting another member to owner and demoting the existing owner happens via the dashboard’s “Transfer ownership” affordance, which runs the necessary safety checks. The API enforces this itself: PATCHing role_id to your org’s owner role is rejected with 409 conflict ("Ownership cannot be assigned via the API."). This is an API-level guard, not a database constraint.

​
Remove a member

DELETE /team/members/{id} soft-removes the row (status = "removed"). The user keeps their profile but loses access to your org. Fires member.removed.
cURL
Returns 204 No Content on success.
Removing a member does not delete their work — articles they authored, conversations they handled, and notes they wrote stay in place. Only their access is revoked.