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; a re-presentation that arrives while the block is still unconfirmed gets the same 402 and the same token again. A reply served for a payment is kept for ten minutes: re-present the same PAYMENT-SIGNATURE for the same method, URL and body and the same reply comes back with X-Nano-Replay: true (a reply given again, never a refusal, to the payer). The block is public and anyone could wrap it, so when the payment echoed the extra.session of the 402 it paid (every 402 here carries one; a v2 client echoes it by copying the accepted entry) the replay goes only to a payload echoing the same session; a payment that echoed no session (extra is optional in x402 v2) is replayed to whoever presents the same block for the same method, URL and body within the ten minutes, which is the only binding there is in that case. 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? ok:true needs BOTH an amount side and a recipient side, every call: amount side: min_raw=N, min_nano=X, or any=1 (amount not checked; the answer then carries min_raw: null, any_amount: true) recipient side: to=A, or any_to=1 (any recipient; the answer then carries expected_to: null, any_to: true) a call with only one side answers ok:false and the reason names the missing side (since 2026-09-29 for the amount, 2026-09-30 for the recipient; never a 400, found still answers). a seller that passes only any_to=1 gets ok:false, which is the safe answer. combined calls: ?hash=H&min_raw=N&to=A paid at least N raw to A (the normal check) ?hash=H&any=1&to=A any confirmed send to A ?hash=H&any=1&any_to=1 any confirmed send to anyone min_raw is at most 2^128-1 (340282366920938463463374607431768211455), min_nano likewise; above that the answer is 400 (since 2026-10-01) (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); min_raw (or min_nano) is at most 2^128-1, else 400 (since 2026-10-01) 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; for a payment block H is your account frontier (the block's previous), never the new block's own hash (pyfile-toolkit, 2026-10-05). 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