Skip to main content
When an agent payment exceeds its approval threshold (or a policy rule flags it), it waits in the approvals queue for a human decision. See Approvals for the concept overview.

​
List pending approvals

Returns payments awaiting a decision. Each item includes the agent, amount, recipient, the agent’s stated purpose, budget context, which rules flagged it (flaggedByRuleTypes), and expiresAt — the end of the human decision window.

​
List completed approvals

Returns resolved requests with their resolution: These are the human REST feed’s resolution values. Agents use the separate wallet-payment status contract: pending, executing, settled, failed, denied, expired, or not_found. The owning agent polls get_payment_status with the payment’s request_id on its agent-key connection; an organization key cannot call that tool. Human approval alone does not establish settlement. See Payment Workflow. The owning agent can set wait_seconds (integer 0–60, default 0) on get_payment_status to wait for a status or step change; terminal results return immediately. Honor retry_after_seconds: about 10 seconds for a new executing payment, then 30 seconds; pending starts at 30 seconds and backs off to 300 seconds as it waits. Retrying a timed-out read uses the same request_id, not a new payment. The two agent payment tools use the same network-selection rules. The first payment to a new EVM recipient requires caip2; later omission uses this agent’s settled history only if it has exactly one network, while Solana can be inferred from address format. An explicit network wins. CHAIN_REQUIRED refuses before an approval is created: ask for the network and retry with the same idempotency key. The approval card shows the network and why it was selected. For backend push, subscribe to approval.completed webhooks; expired approvals produce no such webhook. This is an approval result, not proof of settlement. The agent must continue get_payment_status to a final result: current transaction webhooks lack request_id correlation and omit failure/expiry/reversal outcomes, so they cannot replace per-payment tracking. See webhook limits. MCP resource subscriptions are a later design path with no promised date.

​
Approve

No body. For wallet payments, Reinx executes the transfer immediately on approval.

​
Deny

feedback is required (1–1,000 characters) — it’s delivered to the agent via the get_denial_feedback MCP tool so it can adjust before retrying.
Approving and denying are deliberately quick actions — no step-up re-verification — because each one releases a single, already-policy-validated payment with a fixed amount and recipient.