Skip to main content

​
List transactions

Returns the organization’s transactions, newest first, cursor-paginated.

​
Query parameters

​
Response

Statuses in this REST transaction feed: approved, pending, denied, failed, reversed, expired, cancelled. This feed retains its REST field names and display-status vocabulary. MCP list_transactions uses snake_case fields such as amount_cents, next_cursor, payment_type, and recipient. The owning agent can track execution with get_payment_status on its agent-key connection, using the separate seven-status wallet contract, including executing and settled. An organization key cannot call agent-band tools; it continues to read this transaction feed. See Payment Workflow for the agent flow. The agent’s get_payment_status accepts wait_seconds (integer 0–60, default 0). It long-polls until a status or step change, a terminal result, or the wait elapses; a terminal payment returns immediately. Executing is still in flight, not settled. Honor the returned retry delay (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), and retry a timed-out read with the same request_id. Agent payment responses also include chain_name, chain_source (provided, recipient_history, or address_format), and, for history selection, chain_source_request_id and chain_source_settled_at. Older records may have null selection context. These agent fields do not rename the REST feed’s chainCaip2 or other fields. For a per-recipient summary, the agent can call get_spending_summary. Its additive by_recipient entries include recipient, chain_caip2, chain_name, spent_cents, transaction_count, and last_settled_at, grouped by wallet recipient and network. Wallet recipients also remain in by_merchant; neither output replaces the other. Bots sharing an agent key share that agent’s history and budget. approval.completed webhooks push approval decisions to your backend; approval does not establish settlement. transaction.completed notifies successful transactions, but has no payment request_id and omits failure, expiry, and reversal outcomes. It cannot replace the agent’s get_payment_status reconciliation to a final result; see webhook limits. MCP resource subscriptions are a later design path; agents can use long-poll today. Pass nextCursor back as cursor to fetch the next page; nextCursor is null on the last page. A malformed cursor returns 400 BAD_CURSOR.

​
Export transactions

Streams the filtered range as CSV. Accepts the same filters as the list (minus pagination), plus:
Approving and denying pending transactions lives under the Approvals endpoints.