SDK — define a customer role for a business account
Defines a role that inherits a built-in one. The role lives only in the signed authorization document, so there is no separate role resource. 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"
Body
SDK defineRole body. A customer role always inherits a built-in one, which is what lets capability lookups and existing rules resolve through it.
Lowercase letters, numbers, hyphens and underscores.
admin, viewer 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 defined; the new document version returned
The new version of the signed authorization document.