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

# Approve

> Review exact terms and complete sensitive browser steps without widening authority.

Act pauses before consequential work when the user must provide information, access, payment, or an exact approval.

| Pause                 | What it asks for                               | What it does not grant                                   |
| --------------------- | ---------------------------------------------- | -------------------------------------------------------- |
| `awaiting_user`       | Missing information or a clarification         | Approval or payment authority                            |
| `connection_required` | User-controlled access to a provider           | Permission to spend, approve, or save the connection     |
| `payment_required`    | Completion of a bound first-party payment flow | Standing authority for future purchases or changed terms |
| `approval_required`   | One decision over an exact reviewed payload    | Approval of a changed revision or payload                |

## Approve an exact review

Only show approval controls when `availableActions` includes `approve`. Send the values returned by Get action without modifying them.

```json theme={null}
{
  "approvalId": "approval_123",
  "decision": "approve",
  "expectedRevision": "2026-09-19T16:30:00.000Z",
  "reviewedPayloadDigest": "sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
  "requestId": "invoice-1042-approval"
}
```

If the payload, price, merchant, cart, revision, digest, or expiry changes, the previous approval is invalid. Read the current Action and ask the user to review again.

An approval applies once to the exact reviewed decision. It cannot be inferred from a message such as “looks good,” from a previously approved revision, or from a general account preference.

<Steps>
  <Step title="Read the current Action">
    Confirm `availableActions` contains `approve` and capture the current review fields.
  </Step>

  <Step title="Show the exact decision">
    Present the provider, scope, material terms, expiry, and every consequential value without model-written
    substitutions.
  </Step>

  <Step title="Collect one explicit choice">
    Let the user approve or reject. Do not preselect approval or infer it from unrelated conversation.
  </Step>

  <Step title="Submit the bound review">
    Send the exact `approvalId`, revision, digest, decision, and a new mutation `requestId`.
  </Step>
</Steps>

## Complete connection or payment

`connection_required` and `payment_required` can include a typed interaction and first-party Darwin `webLink`. Open it only after a user gesture, keep the Action nonterminal, then poll the same `actionId` for backend-confirmed progress.

Darwin authentication, provider authentication, transcript storage, and spending approval are separate. Completing one never silently grants the others.

Use [Pay](/docs/act/payments) for payment-specific terms and [Authenticate](/docs/act/connections) for OAuth and credential sources.

## Open first-party interactions safely

* Require a user gesture before opening `webLink`.
* Open only the URL returned for the current Action.
* Keep credentials and payment details out of prompts and tool arguments.
* Treat the Action as nonterminal while the browser flow is open.
* Read the same `actionId` after the user returns.

<Warning>
  A closed window is not a success signal. Only the backend-confirmed Action state can advance the workflow.
</Warning>