# Wait for a result

Follow one action from decision to receipt.

Poll `GET /runtime/tool-requests/{requestId}/result`. It only reads, so polling is always safe.

```json
{
  "request_id": "req-7f2a91c4",
  "correlation_id": "00000000-0000-4000-8000-000000000001",
  "decision": "AUTHORIZED",
  "execution": {
    "status": "COMPLETED",
    "connector_invoked": true,
    "connector_status": "SUCCESS"
  },
  "outcome": { "status": "MATCHED" },
  "receipt": {
    "receipt_id": "00000000-0000-4000-8000-000000000001",
    "completeness": "COMPLETE",
    "chain_intact": true,
    "event_count": 14,
    "signature_present": true
  },
  "observed_at": "2026-10-31T10:16:02Z"
}
```

Values above are illustrative.

## Check the receipt

`POST /v1/receipts/{transactionId}/verifications` asks a separate, read-only verifier
to check a receipt. It trusts only its own list of keys: neither the request nor the
receipt can supply one.

- A bad signature still answers `200`, with `verified: false`.
- `503` means the verifier couldn't answer. That never counts as a pass.

To see how a signature check fails, try the sample on [Test results](/proof).

## When to stop polling

Stop when the answer can't change:

- The decision is `BLOCKED`, `EXPIRED` or `ERROR`.
- Execution is `FAILED`.
- Execution is `COMPLETED` or `UNKNOWN` **and** the outcome has been reconciled.

`AUTHORIZED`, `AWAITING_APPROVAL`, `NOT_DISPATCHED` and `PENDING` are never final. Both SDKs include a wait helper that follows these rules, backs off and honours `Retry-After`.

**A missing request and one owned by another agent both return the same 404.**