> For the complete documentation index, see [llms.txt](https://docs.vapinetwork.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.vapinetwork.ai/call/use-call/receipts-and-retries.md). # Receipts and retries Every paid Call request leaves a receipt. Use it to see what you paid, to check an uncertain settlement onchain, and to retry safely when the API supports payment identifiers. A receipt records one paid call: the quote, the settlement and the latency. Use it to see what you paid and to answer the one question a lost response leaves: did that payment settle? ## Where receipts are * The `vapi` client writes a local receipt for every paid call, from the CLI, the MCP server and the SDK alike. They live under `~/.vapi` and never leave your machine. * The console shows the settlement reference on the page after a paid call. The Usage page at `/call/usage` lists the paid calls your connected wallet settled, read from the chain. List receipts: ```bash vapi receipts vapi receipts --limit 20 vapi receipts --all-wallets ``` ``` Wallet: main (0x782F38a2cADbeA094bc89895A1edf965901A7600) 2026-10-15T09:41:12.000Z succeeded GET https://weather.cyberwarex.com/forecast (https://basescan.org/tx/0x...) ``` Each line is the time, the settlement outcome (`succeeded`, `rejected` or `unknown`), the request, and the explorer link when the settlement names a transaction. Export them for a spreadsheet or a ledger: ```bash vapi receipts export --format csv --range 30d vapi receipts export --format json --range 7d ``` `vapi stats --range 7d` sums the same receipts: spend, calls, outcomes, latency and the APIs you used most. ## Check an uncertain payment Slow providers get up to 120 seconds for the paid response by default. Use `--timeout ` to raise the wait, up to 300 seconds and capped at the offer's `maxTimeoutSeconds`. A timeout reports `settlement_unknown`. When a paid call returns nothing, the client refuses to guess and names its receipt. Ask the chain before anyone pays again: ```bash vapi pay --resume ``` ``` Receipt: rcpt_… — POST https://gateway.thegraph.com/api/x402/subgraphs/id/… Authorization: nonce 0x… from 0x782F…7600, USDC 0x8335…2913 on eip155:8453, valid before 2026-10-15T09:46:12.000Z Settled: the authorization was used on-chain, so the payment went through. Do not pay again. ``` The client reads the authorization's state from the USDC contract. It opens no wallet, signs nothing and pays nothing. Three answers are possible: | Answer | Meaning | What to do | | ------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Settled | The authorization was used. The payment went through. | Do not pay again. Ask the provider for the response if you need it. | | Expired | The authorization was never used and its window has passed. | Paying again is safe. | | Pending | Unused, but still inside its window. | Wait until the time printed, then run the command again. Paying now could pay twice. | In MCP, `call.pay` returns `settlement_unknown` in the same situation and names the receipt for this command. An agent should stop and report, not retry. ## Safe retries with payment identifiers Some APIs advertise the x402 `payment-identifier` extension. The client then generates an identifier, sends it with the payment and stores it on the receipt as `paymentId`. Retrying the same request with the same identifier returns the cached response without a second settlement. Reusing the identifier for a different request is rejected. See [x402 extensions](/call/reference/x402-extensions.md).

Two ways to recover a paid call. Response lost: a paid call returned no response, so the payment may or may not have settled; vapi receipts lists every paid call with its ID; vapi pay --resume with that receipt ID reads the authorization's state onchain. No wallet is opened, nothing is signed, and nothing is paid again. Safe retry, when the API advertises payment-identifier: retry the request with the same payment-identifier as the first attempt. With the same request fingerprint you get the cached response and no second settlement. With a different fingerprint the retry is rejected, because the identifier was already used for another request. One identifier means one settlement. — Reconcile with the receipt, or retry with the same payment identifier. Neither pays twice.

## Next * [Pay with the CLI, MCP and SDK](/call/use-call/pay-with-vapi.md) * [How Call works](/call/how-call-works.md) Checked on 2026-10-16. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.vapinetwork.ai/call/use-call/receipts-and-retries.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.