Roles

Update Role

Redefine a role. THIS CHANGES WHAT EVERY HOLDER MAY DO, IMMEDIATELY.

permissions REPLACES the list rather than merging into it, so a value left out is a permission taken away from everyone who holds the role. That is why this operation is tiered destructive rather than write: it is a privilege change, and "re-define what the sales team may do" must not ride along in the same grant as "rename a team".

The app refuses to edit the permissions of its locked system roles (admin, service_provider) - stripping roles:manage from admin would lock the organisation out with no recovery path - and refuses to grant anything the caller does not hold. Both reach you as a 403.

put/roles/{role_id}

Request

  • Base URL: https://be.graph8.com/api/v1
  • URL: https://be.graph8.com/api/v1/roles/{role_id}
  • Auth: HTTP bearer

Path parameters

role_idstring required

Role id (UUID).

Headers

Authorizationstring nullable
X-Target-Org-Idstring nullable

Request body

namestring nullable
descriptionstring nullable
permissionsstring[] nullable
manages_role_slugsstring[] nullable

Response

Successful Response

dataOrgPayload required

An open envelope for a single role, team, member or account record.

Open on purpose. The app's own response models on this surface grow with the product - RoleResponse gained rep_limits and manages_role_slugs, TeamResponse gained channel counts and a campaign count - and a pinned mirror would SILENTLY DROP whatever it had not caught up on. A dropped permission in a role read is the worst possible kind of stale: it reads as "they do not have it".

Changes

No recorded changes to this operation across all 2 revisions of this API.