What approvals provide#
Approvals gate risky actions behind human review. They cover budget overrides, autonomy exceptions, routine decisions, and sensitive operator controls.
Creating approvals#
POST /api/v1/approvals creates an approval request. The system
also creates approvals automatically when governed actions trigger
approval-required policies.
Resolving approvals#
POST /api/v1/approvals/{id} resolves an approval:
| Decision | Effect |
|---|---|
| approve | Action proceeds |
| reject | Action is blocked with reason |
Include an optional comment and reason with the decision.
Discussion threads#
POST /api/v1/approvals/{id}/comments adds a comment to the
approval discussion. Comments are timestamped and attributed to the
commenting user.
Approval types#
Common approval types:
| Type | Raised for |
|---|---|
operator_control | Sensitive operator actions such as requeue, reassign and abort |
sidekick_tool_approval | Approval for a Sidekick tool call |
app_connector_call | Approval for an app connector call |
Sensitive approvals carry a four-eyes rule. The requester of one of these approvals cannot decide it.
A decision is single winner. Once one decision is recorded, a concurrent decision is refused, and the approval is not decided twice.
Operator-control approvals#
When workspace governance requires approval, sensitive actions such as requeue, reassign and abort wait for a decision before they run. Other actions run directly.
Dashboard#
The approvals inbox now lives inside the Sidekick chat surface as a
widget — ask Sidekick to show pending approvals and
the inbox renders inline with decision buttons and discussion threads.
Approval policy (which actions pause for sign-off) lives at
/dashboard/{workspaceId}/settings#approvals.
Transition history#
Every approval state change (created, approved, rejected) is recorded in the transition history with timestamp, actor, and reason.