> ## Documentation Index
> Fetch the complete documentation index at: https://docs.invokehq.run/llms.txt
> Use this file to discover all available pages before exploring further.

# approvals

> Stage agent actions for human review before execution. Invoke re-validates state between approval and execution so stale approvals never fire.

Approval-bound actions pause before executing and wait for a human decision. Invoke stages the action, notifies the appropriate reviewer, and revalidates state before the action runs — so approvals granted on stale context never cause unintended side effects.

## How approvals work

<Steps>
  <Step title="Agent requests an approval-bound action">
    The agent calls `invoke.call()` with a tool classified as `approval-bound`. Invoke immediately stages the action and returns `pending_approval`.

    ```typescript theme={null}
    const result = await invoke.call({
      tool: "issue_refund",
      params: { customer_id: "cust_123", amount: 5000 },
      agentId: "billing-agent",
      idempotencyKey: "refund:cust_123:5000"
    })

    // result.status === "pending_approval"
    ```
  </Step>

  <Step title="Invoke notifies the reviewer">
    The staged action appears in your Invoke dashboard. The reviewer sees the tool, parameters, and the agent that requested it.
  </Step>

  <Step title="Reviewer approves or rejects">
    The reviewer makes a decision in the dashboard or via the API.

    * **Approved** → Invoke proceeds to state revalidation
    * **Rejected** → Invoke returns `blocked` to the agent
  </Step>

  <Step title="State revalidated before execution">
    Before the approved action runs, Invoke revalidates the current state against the conditions that existed when approval was granted.

    If state has drifted — the customer was already refunded, the deployment status changed — Invoke returns `replan_required` instead of executing. The stale approval never fires.
  </Step>
</Steps>

## Why state revalidation matters

Approvals can have long delays between grant and execution. In that window:

* The customer may have already received a refund through another channel
* The deployment may have rolled back
* The target record may have changed

Without revalidation, an approved action executes against a world that no longer matches the context in which it was approved. Invoke catches this automatically.

## Approval outcomes

| Status             | Meaning                                      |
| ------------------ | -------------------------------------------- |
| `pending_approval` | Action staged, waiting for reviewer decision |
| `executed`         | Approved and state validated, action ran     |
| `blocked`          | Rejected by reviewer                         |
| `replan_required`  | Approved but state drifted before execution  |

## Next steps

* [Tool Safety Classes](/concepts/tool-safety-classes) — how to classify tools as approval-bound
* [Traces](/concepts/traces) — inspect the full approval timeline in execution traces
* [Execution Records](/concepts/execution-records) — the durable record created for every staged action