post_v1_commerce_topup_wallet
WalletTopup credits the caller's org for a stablecoin transfer they already sent to the treasury.
WalletTopup credits the caller's org for a stablecoin transfer they already sent to the treasury. It reads the receipt from that rail's chain, confirms a mined, successful ERC-20 Transfer to the rail's treasury, derives USD cents from the on-chain value using the token's own decimals, records the credit, and returns the amount plus the new balance.
The credited amount is the ON-CHAIN value, never a number the caller sends, and the credit lands on the caller's own validated org — there is no way to name a third-party subject. Nothing is credited that the chain did not confirm: a missing, failed or non-matching transaction is refused, and a deployment with no payment rail enabled says so rather than inventing a credit.
| Tool | post_v1_commerce_topup_wallet |
| Door | https://api.hanzo.ai/v1/mcp |
| Method | tools/call (JSON-RPC 2.0) |
| Arguments | 3 |
| Operation | none in the OpenAPI document |
| Product | — |
Arguments
| Field | Type | Required | Default | Values | Description |
|---|---|---|---|---|---|
fromAddress | string | — | — | — | FromAddress is the wallet the transfer was sent from. Optional; when given it must match the transfer's on-chain sender. |
rail | string | — | — | — | Which accepted rail the transfer was sent on, e.g. "base-usdc". The client names it rather than the server guessing from the tx: the same address can exist on several chains, so inferring would risk crediting against the wrong treasury. It may be omitted only while exactly one rail is enabled. |
txHash | string | — | — | — | TxHash is the hash of the ERC-20 transfer that was already sent to the rail's treasury. The receipt is read from that chain; nothing is credited that the chain did not confirm. |
tools/list declares a type and a description for each field and nothing further, and the OpenAPI document describes no operation for this tool. A — above means neither source constrains the field, not that it is unconstrained in practice.
Call it
A tools/call carries every argument in one flat object — nothing binds to a path or a query string. Nothing above is required, so every declared argument is shown rather than a guess at which matter.
curl -X POST https://api.hanzo.ai/v1/mcp \
-H "Authorization: Bearer $HANZO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "post_v1_commerce_topup_wallet",
"arguments": {
"fromAddress": "<fromAddress>",
"rail": "<rail>",
"txHash": "<txHash>"
}
}
}'Values are the operation's own defaults and enumerated values where it declares them, and a <placeholder> where neither source declares one. tools/list needs no credential; tools/call does — called without one the door answers HTTP 200 with a JSON-RPC result whose isError is set and whose text says what was missing. How to get a key →
The operation behind it
The door exposes post_v1_commerce_topup_wallet, but the copy of the OpenAPI document this build holds (pinned at 4e41f04ca) describes no operation for it — neither under that name nor at the route the name implies. That is either a route the document has yet to declare, or one the door has renamed since the pin. Everything on this page comes from tools/list; there is no REST reference to link to until the two agree.
All 755 tools · The door · API reference
Generated from tools/list on https://api.hanzo.ai/v1/mcp — 833 tools captured 2026-08-01, of which 755 are documented here (the operator surface is not published) (this build read the vendored copy; the door was unreachable).
How is this guide?