GET /api/v1/credits for your balance and the deployment’s current top-up options. Do not assume that wallet funds, hosting balance and provider usage limits are the same balance.
What is charged
Explicit verification requests and proposals that reach the judge are charged. Read-only wallet, quote and transaction-status calls do not run a paid check. Desk actions with Chance checks off do not create a paid verdict; normal wallet rules still apply.Top up over HTTP
UsePOST /api/v1/credits/topup?usd=10, authenticated with an API key. A public account top-up code can identify the receiving account instead.
- Request the endpoint without payment. It returns x402 v2 payment terms in
PAYMENT-REQUIRED. - Read the exact USDC amount, recipient and Base network from those terms.
- Sign with your x402 client and retry with
PAYMENT-SIGNATURE. - Check the successful response. The balance is credited after settlement.
credits requests are still supported; use the limits returned by the API. Sending a plain USDC transfer to a treasury address does not credit the account.
Top up over MCP
Usetopup_credits with a USD amount. Without payment it returns the x402 terms. A payment-capable client can repeat the request with the signed v2 payment in its metadata. A chat client without a signing wallet should direct the owner to the account top-up flow.
Retries and insufficient balance
An ordinary verification402 response means insufficient balance; it is not itself an x402 invoice. Pay through the top-up endpoint, then retry the check.
If a payment’s result is unclear, reuse its existing payment authorization when checking or retrying. Do not create another payment just to recover a lost response. A temporary facilitator failure does not establish that funds never moved.