SDK — approve a proposal
Records the caller’s consent, signed with their session key. Requires step-up authentication: approving is the act that authorizes the mutation, so it carries the same weight as performing it.
Recording an approval does not apply the change — call execute once the requirements are satisfied. An initiator can never approve their own intent; the enclave refuses it and so does this endpoint.
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"
ID of the business account proposal
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 approveProposal body. The signature is over the proposal's stored intent together with approvedAt, produced by the approver's session key — which never leaves their device, so approving cannot be done on their behalf.
Response
Approval recorded; the proposal with its current approvals
A governed mutation waiting on consent. Untrusted workflow state: it records what was proposed and who has signed, and the enclave verifies every signature when the proposal is executed. The signature is over intent as stored, so an approver must sign these exact bytes — re-deriving the intent would produce a different intentId and invalidate the approvals already collected.
A business-account mutation that an approval requirement can gate.
addMember, removeMember, updateMemberRole, transferOwnership, createWallet, linkWallet, removeWallet, addSignerToWallet, removeSignerFromWallet, setGovernance, defineRole, deleteRole Lifecycle of a governed mutation awaiting approvals. Only pending accepts approvals; the other three are terminal.
pending, executed, vetoed, expired Who proposed it. They can never approve their own intent, so they are never counted toward a requirement.
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.
The one deadline for the whole proposal, derived from the signed intent's createdAt. Past it the proposal accepts no further approvals AND can no longer be executed.
When it left pending; null while still open.
Whether this applies as soon as its quorum is met, or waits for an explicit execute. A copy of the flag inside the signed intent, which is the authority. An approver needs this to know whether their approval is the one that lands the change.
The users this change is about, resolved for display — the member being added, the signer being removed, the new owner. Empty for a change that names no user, such as setGovernance.
Every governance rule matching this proposal, with how close each is. Do NOT derive progress from approvals — that counts rows, including approvers outside a rule's pool and approvers demoted since they signed.
Absent means the tally is unknown (not fetched, or no longer pending); an empty array means nothing is outstanding. Treat the two differently.