Networks & assets
Agentic payments move money through the same rails as the rest of the platform — anything your wallets can send, an agent-drafted payment can send:
Sandbox examples throughout these docs use
base-sepolia, ethereum-sepolia, and solana-devnet with USDC.
How many times an auto account converts
An auto account’smax_transactions caps how many sweeps it performs before it stops converting — a sweep being one convert-and-forward of funds received at the account through to its destination.
This is what bounds a recurring series: one account serves the whole schedule and then disables itself, rather than remaining live indefinitely after the last payment. Set it to the number of payments in the series.
Mandate rule bounds
A mandate holds exactly one rule at a time. Each rule is an immutable, separately-signed version; a mandate’s authority changes by amending it, which appends a new version rather than editing the old one. The outgoing version is never rewritten and stays readable atGET /mandates/{mandate_id}/versions.
Every cap is enforced at fire time by the mandate gate — a schedule that outgrows its mandate fails with
mandate_denied rather than firing.
Aggregate and per-target caps are different ceilings
The two families are checked independently, and a rule may set either, both, or neither. Getting them confused is the most common way a mandate ends up authorizing more than intended:max_amount_in_windowis one shared budget. Three payees against a"10000"monthly aggregate can spend 10,000 between them.max_amount_per_target_in_windowis a budget each. Three payees against a"10000"monthly per-target cap can spend 10,000 each — 30,000 a month — and adding a fourth payee raises the ceiling to 40,000 without any amount field changing.
max_amount_in_window. A per-target cap on its own bounds no total.
Windows are UTC calendar periods
Every window resets on a UTC calendar boundary, not a rolling interval and not the customer’s local midnight. A rolling 30 days would wrongly deny “the 15th of every month” whenever consecutive months are less than 30 days apart; a drifting reset time would creep forward forever. The practical consequence: a payment your customer reads as next month can be metered into this one. For a customer at UTC+1, a payment due1 Aug 00:25 local is 31 Jul 23:25 UTC and is charged against July’s budget. A daily series of ten payments starting 29 Jul 00:25 local puts four into July, not three. If you display scheduled dates in local time, expect this to be visible to your users and worth explaining.
Amending preserves spend
Usage accrues to the mandate, not to the version. An agent that has spent 9,000 of a 10,000 monthly limit and is amended to 20,000 has 11,000 left, not 20,000. This is the whole reason amendment exists: cancel-then-create silently handed the agent a fresh budget, because usage is recorded per mandate and a replacement starts with empty buckets. Amending never re-buckets history either — which is whywindow is frozen across versions. Usage rows carry no window label, so changing MONTHLY to DAILY would retroactively reinterpret every past spend.
Conversation & drafting caps
Budget overruns return
429 with a Retry-After-style problem body; input-cap violations return 400 before any model spend.
Platform-wide limits that apply here too
- API rate limits — the standard per-key limits apply to every agentic endpoint; see Rate limiting.
- Idempotency — every agentic
POSTrequiresX-Idempotency-Key, like the rest of the platform. - Sandbox amount cap — sandbox caps transactions at $2 USD-equivalent per transaction by default, agentic ones included. Drafts above the cap actuate but fail at fire time, exactly as an over-cap direct send would.