Pay per call: DNS Doctor's x402 burst lane for AI agents

An AI agent that hits our rate limit has, until now, had exactly one option: wait. It cannot sign up, it cannot read a pricing page, and it certainly cannot enter a card number. So it stops — mid-task, with the answer one call away.

DNS Doctor's public API now offers it a second option. Past the free per-caller rate limit, three endpoints answer HTTP 402 Payment Required with a machine-readable offer: $0.01 in USDC on Base, per call, over the x402 protocol. The agent's wallet signs, retries with a payment header, and gets its answer. No account, no key, no human in the loop.

Which calls

Three anonymous REST surfaces an agent already uses, each free until its own per-caller rate limit:

And eight that work differently, paid on every call — there is no free allowance to spend first. They add surfaces rather than paywalling one: nothing above them changed.

A batch is charged only when it read something: a bulk lookup where every registry timed out, a propagation batch where no check reached enough locations to give a verdict, or a report batch where no file parsed, is answered and not settled.

The watches sell time rather than an answer: one payment buys the window, the 402 quotes the exact amount for the window and cadence you ask for (the lookalike watch is sold only as the whole day, at one price), and the handle you get back polls for free until the results expire. The lookalike watch's first reading is the baseline, the close names that resolve; after that a change is a name that starts or stops resolving, starts accepting mail, swaps a parked page for a real website, or changes its page title. The egress rules for the ping watch — public destinations only, standard web ports, fleet-wide caps on any one target — are the product.

The offer lives at /.well-known/x402.json, and the always-paid URLs are listed for crawlers at /.well-known/x402, but a wallet should read the real requirements from the 402 of the call it actually wants to make — a v2 client from the PAYMENT-REQUIRED header, a v1 client from the JSON body.

What $0.01 buys

One call beyond your own rate limit. That is the whole product, and the boundary is deliberate — it is the part worth reading twice if you build agents.

Payment lifts the per-caller limit and nothing else:

• The per-target budget still applies. A domain can only be scanned so often, no matter who is asking or what they paid. Money buys you a place in the queue, not the right to hammer someone else's DNS.
• Failures are never charged. We verify the payment, run the call, and settle only after a 2xx. If your paid call is refused by the target budget, or if our probe fleet is down and the propagation check returns 503, the payment is held and never settled — the funds stay in your wallet.
• Nothing is unlocked that money should not unlock. The AI explanation gates, the deterministic fix engine's rules, the never-write-your-DNS promise: all identical on a paid call.

What stays free

Everything that was free yesterday. The scan, the report pages, the MCP tools, the standalone tools — all of it, at the same limits, with no wallet anywhere near it. The paid lane exists for the agent that wants more throughput than free allows, not as a toll on the front door.

If you are a human reading this: nothing on this site asks you to pay, and no page has a wallet in it. The one way you could meet a 402 at all is by running the propagation checker past its free per-caller limit — and there the page just tells you to wait; there is no purchase to make and nothing to sign.

Wiring it up

Point your agent's HTTP client at the endpoints above with x402 payment middleware and a funded Base wallet, and the 402/retry round-trip is handled for you. Verified end to end with the v2 client stack — @x402/fetch plus @x402/evm, registering the exact scheme for eip155:8453:

const client = new x402Client();
client.register("eip155:8453", new ExactEvmScheme(toClientEvmSigner(account)));
const paidFetch = wrapFetchWithPayment(fetch, client);

One compatibility note worth having before you build: both protocol eras are served from the same 402. A v2 client (@x402/fetch + @x402/evm) reads the offer from the PAYMENT-REQUIRED header and gets its receipt on PAYMENT-RESPONSE; a legacy x402-fetch@1.2.x client reads the v1 document — maxAmountRequired, a bare-string resource — from the JSON body, pays with X-PAYMENT, and gets its receipt on X-PAYMENT-RESPONSE. Both halves have been exercised against production with funded wallets; the v1 half is served for legacy x402-fetch@1.2.x clients — build on v2 if you have the choice.

No ETH is needed on the payer side: exact settles by signed EIP-3009 authorization, and the facilitator pays the gas.

Payments settle directly between your wallet and ours, on-chain. That means there is no merchant of record, no invoice beyond the transaction itself, and no way to reverse a settled payment — see our terms and refund policy for the exact wording.

Why bother

Because the interesting question is no longer "can an agent use this tool", it is "can an agent use this tool without a human provisioning it first". Signup flows, API keys and billing pages are all human-shaped. A 402 is not. We think DNS is a good place to find out what changes when the tool can simply be paid.

The watch tasks are live now: a propagation watch, a DNS record-change watch and a five-region HTTP ping watch, each paid once for a window of up to 24 hours, plus a lookalike watch paid once for a fixed day, all polled by handle, with the egress rules published on the methodology page. What agents actually buy, and what it adds up to, we will publish once the numbers are large enough to mean something.