SDK — delete a customer role from a business account
Refused while the role still holds members or is named by an approval requirement, so a delete cannot strand people or leave a rule unsatisfiable. Requires step-up authentication.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
ID of the environment
36^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"95b11417-f18f-457f-8804-68e361f9164f"
ID of the business account
36^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"95b11417-f18f-457f-8804-68e361f9164f"
Name of the customer-defined role. Lowercase letters and numbers, with - and _ allowed inside, 1–32 characters.
^[a-z0-9](?:[a-z0-9_-]{0,30}[a-z0-9])?$Body
SDK deleteRole body. Only the approval artifacts — the role itself comes from the path.
Whether the change applies the moment its quorum is met, or waits for an explicit execute. Read only on the first call, where it is stamped into the intent you sign; after that the signed intent is the authority. Defaults to true, because a change holding all its consent while waiting for a button press tends to be forgotten, and the deadline covers execution too.
The initiator's proposal, signed with their session key. Built by the API, not the client — sign these exact bytes verbatim, because re-serializing can change them and invalidate the signature.
autoExecute is inside the signed bytes, so an approver consents to it and nothing can flip it afterwards.
Response
Role deleted; the new document version returned
The new version of the signed authorization document.