Skip to main content
Delegrity

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.

{
  "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.

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.

View as Markdown