Agentic payments with local spending limits

Agentic payments are payments an AI agent makes for the data or tools it uses. With vAPI Network, an agent reads an API's live x402 price and signs one exact USDC payment from a wallet on the buyer's machine. Per-call and daily caps limit what that wallet may spend before it signs.

ItemCurrent state
vAPI CallLaunching. The console does not serve Call yet.
Paymentx402 v2 exact, in USDC
SigningBuyer-local wallet, one authorization per request
Spend limitsPer-call and UTC-day caps, checked before signing
Checked on2026-10-02

What the agent is allowed to pay

A payment starts with an API request. The API answers 402 Payment Required with an offer naming the amount, network, asset and recipient. The client checks that offer against the wallet's limits. If it accepts, the local key signs a payment for that request and the client sends the request again with the payment attached.

The signature fixes the recipient, amount, token, chain, nonce and validity window. vAPI Network never signs for a buyer and holds no buyer balance. An agent's ability to ask for a tool does not give vAPI control of the wallet. Keep only a small working balance in the local account and protect its keystore and passphrase.

The payment options an agent may find

A directory can describe a payment method without being able to pay it. Call's supported path is an exact USDC payment over x402. Other offers can appear in external APIs, so inspect the payment method before you build an agent around it.

OfferWhat vAPI supports
x402 exactOne fixed USDC amount per request, payable by vapi-network
x402 upto or auth-captureMay appear in external APIs; not payable through vAPI
MPP (Stripe/Tempo)Recognized in the directory; not payable through vAPI

vapi-network supports exact USDC offers on Base and Arc, with Arc Testnet opt-in. A supported network is only one check: the offer must also use the supported scheme and canonical USDC. The API's live 402 is the source of truth for the amount and payee. A stored directory price can be stale by the time the agent asks to pay.

Set standing caps and a one-call maximum

Set a per-call cap to bound one payment and a daily cap to bound spending across the UTC day. A lower maximum on a particular call narrows the permission for that request. The client reads the live offer and applies these checks before signing, even if the agent already found and inspected the API.

These commands are copied from the documentation Quickstart. The amounts are its example limits, not API prices or required defaults. Production discovery opens when Call launches.

vapi accounts caps main --per-call 0.05 --per-day 1
vapi search "weather"
vapi inspect <listing-ref>
vapi pay <listing-ref> --max 0.02

Search and inspect are free. Only the payment step signs an authorization. 5% network fee on self-listed APIs, nothing on indexed listings. The provider's splitter takes the fee from the advertised amount, so the buyer pays the live quote without a vAPI markup.

Use the same account from your agent

The CLI, local MCP server and SDK use the same buyer-local payment model. In an MCP client, an agent uses call.search, call.inspect and call.pay; the payment tool accepts maxPriceUsd. The SDK also accepts network and expectedPayTo to constrain the live offer. Wallet credentials stay on the buyer's machine.

The client writes a local receipt for each payment attempt. If the response is lost, check that receipt's settlement state before trying again. The documented resume command checks the existing authorization onchain without signing or paying again. A missing response alone does not establish whether the USDC moved.

vAPI documentation

On this site