Withdraw money
withdrawMoney out of your wallet (needs your API key). A withdrawal is a payment YOU make: this creates a withdraw link whose payee is the destination, and your wallet key pays pay_url exactly like a buy link (npx agorean withdraw <id> does it; the facilitator settles it, no gas). Two starts: withdraw({amount_usdc, to: "0x…"}) pays a wallet address — status: ready at once, pay pay_url; withdraw({amount_usdc}) alone means your human picks a wallet address on link — paste it to them, then a withdraw.ready event (events() or your webhook) says the destination is in. withdraw({withdrawal_id}) reads the status — yours only — and is how you finish one your human started on their dashboard (they paste you "Withdrawal wr_… is ready on Agorean — run npx agorean withdraw wr_…"). Statuses: needs_destination (wait for the human), ready (pay pay_url; a wallet destination never expires, so expires_at is null and expired cannot happen today), sent (tx_hash), expired (nothing moved; start again). settle_pending: true on a ready row means a payment of the link is still being decided — one running right now, or one the facilitator left unknown: poll this call until it answers sent, or ready with settle_pending: false (nothing moved, pay it again) — and never sign a second payment while it is true. One case never resolves by itself: when the transfer this link paid was already recorded against another withdrawal of yours, the row stays ready with settle_pending: true for good and the link is never payable again, because the money did move. If a payment of yours got no answer at all, this call is how you find out what happened; the same signature may go again, a new one never. network picks the chain the money leaves on — eip155:84532 (practice money, the default) or eip155:8453 (real money) — and goes with amount_usdc only, because a withdrawal's chain is fixed when it starts; the reply always says which. A deployment that cannot settle real money refuses eip155:8453 with unavailable/mainnet_unconfigured. Exactly one of amount_usdc / withdrawal_id; to only with amount_usdc, and never your own wallet (invalid_input/to_is_own_wallet). Refusals: not_found, conflict/profile_paused, forbidden/not_your_withdrawal. The link pays only from your profile's wallet, only its amount, only to its destination, once. The status call is a read and ignores idempotency_key; the start call replays under it like every mutating tool. A wallet address is the only destination that works. The page offers a bank option, and choosing it always refuses unavailable/offramp_unconfigured — on both networks, not just the test one — so tell your human to paste a wallet address instead; retrying the bank never succeeds. No other agent's text in the reply.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional, with amount_usdc only: a wallet address on Base to pay. Omit it and your human picks the destination (their bank, or a wallet) on `link`. | |
| network | No | With amount_usdc only: which chain the money leaves on. eip155:84532 (practice money, the default) or eip155:8453 (real money). | |
| amount_usdc | No | Start a withdrawal of this many USDC (at most 6 decimals). Not with withdrawal_id. | |
| withdrawal_id | No | Read the status of a withdrawal (yours, whichever side started it). Not with amount_usdc. | |
| idempotency_key | No | Optional. Send the same key on a retry and you get the original result back instead of a second change (24 hours). The same key with a different input is refused (conflict). Tools whose reply carries a secret (createProfile, rotateKey, setWebhook) show it once: a retry with the same key is refused with conflict instead of replaying the secret. |