Pay an API call on Etherlink.

Why the tool you already have will not do it

Both of the obvious answers fail on this chain, and neither fails loudly.

• AgentCash does not list eip155:42793 among its networks, so it declines the rail outright.
• The generic x402 exact Permit2 signer produces a well-formed envelope that the facilitator rejects: its canonical proxy is not deployed on Etherlink, and its two-field Permit2 witness does not match the proxy that is.
• A first payment needs a setup transaction — a one-time Permit2 approval that the wallet sends itself, costing about 0.002 XTZ in gas. Miss it and every payment fails for a reason no error names.

What you run

Two clients with identical flags, and identical output down to the wording — every amount, every command and every sentence a person is asked to act on is the same from either. Only hint and warnings, which are notes to the caller rather than instructions to a person, are worded independently. One for node ≥ 20 or bun, one run through uv, which fetches its own Python and the two libraries it needs. Pick whichever the machine already has — neither asks you to install a dependency yourself.

cd x402-etherlink
C='uv run scripts/x402_etherlink.py'   # or: node scripts/x402-etherlink.mjs
Q='https://3route.agents.bakingbad.dev/api/v6.1/42793/quote?src=...&dst=...&amount=1000000'

$C wallet status "$Q"   # can I pay at all, and what does this cost
$C --preflight  "$Q"    # signs nothing; hands back the exact paying command

A wallet that has never paid on Etherlink pays nothing until its one-time Permit2 approval is on chain, and that is two more steps — --approve prices the setup transaction without sending it, --approve --broadcast-approval sends it and then pays. After that, every call is pure USDC and no XTZ is touched again.

Every run prints one JSON object carrying the endpoint's own response under data. paid is true only once the facilitator confirmed settlement — a 200 alone is not proof — and settlementCheck says whether the chain agrees. A spending cap is on by default at 0.01 USDC, raised with --max-amount, and refuses anything above it before signing.

The key never reaches the agent

No command reveals the key, and none accepts a passphrase as an argument. The unlock window is refreshed by signing, not by being looked at, so an agent polling while idle cannot hold a wallet open. Fund it with what the agent may spend — that balance is the real limit.

Read before you install