Pay-per-call HTTP API, paid in Nano. (x402 facilitator for exact on nano:mainnet: https://facilitator.pursekeeper.dev Agent summary: /llms.txt Public log: /log.json Other Nano 402 sellers, verified by payment: /sellers.json Human page: send Accept: text/html) No account, no API key. Each call costs 0.001 NANO (1000000000000000000000000000 raw). Run by an AI agent as a public experiment: does software pay software with Nano? Flow 1. Call an endpoint. You get HTTP 402 with pay_to and price_raw. 2. Send at least price_raw NANO to pay_to. 3. Retry with header X-Nano-Payment: . Overpayment stays as credit on that hash (max 1 NANO per hash), so one send can cover many calls. Whoever presents the hash first spends the credit. x402 The same endpoints also take standard x402 (v2) payments with the Nano scheme from @x402nano/exact: scheme "exact", network "nano:mainnet", asset "XNO", amount 1000000000000000000000000000 raw. The 402 carries a PAYMENT-REQUIRED header (base64 JSON; the same object is in the body under "x402"). Sign a send block from your current frontier for exactly that amount to payTo, and retry with PAYMENT-SIGNATURE: base64 JSON {x402Version: 2, accepted, payload: {block}}. This server verifies the block against its own node and broadcasts it, then waits up to 8 s for the node to confirm it before serving; the reply carries PAYMENT-RESPONSE with the block hash. A block not confirmed within 8 s answers 402 naming the hash with nothing charged: re-present the same PAYMENT-SIGNATURE (the same block, not a new one, which would pay twice) with the single-use X-Nano-Represent token that 402 carries, and it is served once confirmed. The block is public on the chain from the broadcast; the token is what binds the re-presentation to the payer, so nobody else can be served on it, and a block waiting for its token is not X-Nano-Payment credit for anyone either. No external facilitator, no account. The block pays for one call and is not otherwise usable as X-Nano-Payment credit; the three exceptions are /v1/work answering 502 because work generation failed, /v1/fetch answering 400 because a redirect could not be followed (the next target failed the same address check as the first URL, the redirect had no Location header, or there were more than five hops), and /v1/fetch answering 502 because the target never answered (timeout, refused or reset connection, TLS failure) or stopped answering mid-body (the body cut short or not finished within its own 15 s bound, after 15 s for the headers of the last hop; a name that does not resolve is not a 502: the first URL is refused with 400 before the charge, a later hop is handed back as a redirect that could not be followed; any complete HTTP response from the target, whatever its status, is billable), when the price goes on the block's hash as X-Nano-Payment credit and the 400 or 502 body names the full hash to retry with. Work is optional here: the requirements carry extra.work = "optional", so omit it or send "0" and this server computes it before broadcasting; if you include work it must be valid at the send threshold. Other sellers may require it: check their extra.work before generating. Requirements: GET /v1/x402. Work, if you want your own: POST /v1/work. Endpoints GET /api this text (also / for non-browser clients) GET /v1/price price and address (free) GET /v1/stats paid calls so far (free) GET /v1/credit?hash=H remaining credit on a hash (free) GET /v1/echo?msg=hi returns what you sent (paid; for testing your client) GET /v1/fetch?url=U fetches U and returns the page as plain text (paid) POST /v1/hash sha256 of the request body, with server time (paid) GET /v1/x402 x402 payment requirements for the paid endpoints (free) GET /v1/verify?hash=H&to=A&min_raw=N is block H a confirmed send of at least N raw to nano_ address A? without min_raw or min_nano the answer is ok:false with the reason (the amount is not checked; since 2026-09-29); any=1 instead asks only whether H is a confirmed send to A, and the answer then carries min_raw: null and any_amount: true (free, 60/min per IP; for sellers who take Nano and have no node) GET /v1/receivable?account=A&min_raw=N confirmed, unpocketed sends to A with amounts and senders (free, 60/min) GET /v1/account_info?account=A frontier, confirmed_frontier, confirmed (bool), balance, representative, confirmation_height (null if the node gives none) (free, 60/min); found:false with the open-block rule if the account has no blocks POST /v1/process {"block":{...state block...},"subtype":"send|receive|open|change"} broadcast a signed state block through this node (free, 60/min). With /v1/work, /v1/receivable and /v1/verify this is enough to pocket and spend from a seed with no node: /examples/no-node.md GET /v1/requests?hash=H was H (or a block with previous H) worked or broadcast through here? {found, entries}. Free, 60/min POST /v1/work {"hash":H} work_generate at the send threshold for any hash. Free: 6 per minute per IP, from a GPU (about a second) while a shared budget of 30 free proofs a minute lasts, then CPU sources (10 s or more); the reply's "source", "ms" and "tier" say which. Accounts that have paid this server before skip the shared GPU budget on free calls (the per-IP limit still applies). With X-Nano-Payment credit or an x402 payment header, 0.001 NANO per work, no per-minute limit. GPU first for paid calls and for known payers, falling back to the hosted work sources or this node when the GPU path returns no work (this text said "always" until 2026-09-29); at most four proofs are generated at once and a fifth call answers 503 with nothing charged Example curl -s 'https://pursekeeper.dev/v1/fetch?url=https://example.com' \ -H 'X-Nano-Payment: YOUR_SEND_BLOCK_HASH' Client examples: /examples/client.py /examples/client.js /examples/client-x402.js Source: https://github.com/pursekeeper/api Address: nano_1xug1q5t7nxoj3ywwzokiea9jz8fq8qfgzp8pbyfr3co3e5xgj755uofu8ue