Sato Hub

Numbers · x402

How many endpoints that declare x402 actually answer a payment request?

Of 64 endpoints declaring x402, Sato Hub reached 60 and 2 answered HTTP 402 with a payment payload a client could parse; no payment was sent, as of 2026-09-12.

Declare x402

64

one per host × listing, from the candidate set

Reached

60

4 gave us nothing — unknown, not failed

Answered a real 402

2

parseable payment payload, within 7 days

Share of reached that answer

3.3%

of the 60 we reached

Answering, facilitator reachable

0

the declared facilitator answered /supported on its own host

What the gap between these numbers is

Declaring x402 costs nothing: a tag, a line in a manifest, a mention in a README. Answering one means a server is running, priced, and returns HTTP 402 with a payload a client can act on. Neither number is a safety or solvency claim, and we never send a payment — so delivery is never observed. A blank is unknown, never a failure, and a check older than 7 days stops counting as standing rather than flipping to a negative.

Settlement networks the answering payloads declared

NetworkEndpoints
eip155:84532

A declared network is what the seller says it accepts. We did not pay, so no settlement was observed. These rows count endpoints, not payments, and are never added to any other population.

Method
One GET per declared endpoint (POST retried on a 405), redirects not followed, a 10-second deadline. A payment payload counts when it parses as x402 v2 in the body (accepts[] or paymentDetails) or as v1 in the headers. The facilitator named in that payload is asked for /supported on its own host only.
Population
Directory listings whose standards field contains x402, plus resources declared by any /.well-known/x402 manifest found on those hosts. The Coinbase Bazaar catalogue is a different population, measured separately; the two overlap and must never be added.
Per endpoint
Every host and what it did is on x402 verified. This page is the counts only, so the two cannot drift into two different tables of the same endpoints.
Reproduce
GET /api/export/adoption.json → rows where venue="x402_verify" · stages answers_402, candidate_endpoints, answers_402_rate

Questions this page answers

How many x402 endpoints actually answer a payment request?
2 of the 60 we reached (last checked 2026-09-12), inside a 7-day window. 58 answered something that was not a parseable 402, and 4 gave us nothing at all — those are unknown, not failures.
What share of declared x402 endpoints answer?
3.3% of the 60 reached (last checked 2026-09-12). Endpoints we could not reach are excluded from the share rather than counted as failures, so this is a rate over observations, not over the declared population.
Why is declaring x402 different from answering it?
Declaring costs nothing — a tag on a listing, a line in a manifest, a mention in a README. Answering means a server is running, configured with a price and an asset, and returns HTTP 402 with a payload a client can act on. The gap between the two numbers is the whole reason this page exists.
Which networks do the answering endpoints settle on?
eip155:8453 (2) — as declared in each 402 payload. A declared network is what the seller says it accepts; we did not pay, so we did not observe a settlement.
Does an answering endpoint mean paying it works?
No. It means that on the date shown, that URL returned HTTP 402 with a payment payload a client could parse. No payment is ever sent, so delivery, solvency and honesty are never observed and are never claimed. A check older than the window stops counting rather than flipping to a negative.

Sources — the x402 specification and the HTTP status it uses

Data CC-BY-4.0 — attribution: data by satohub.ai. A standing 402 is a statement about a protocol response on a date, nothing else.

Cite this page

Sato Hub. "x402 endpoints: declared, reached, answering." Sato Hub, updated 2026-09-12, accessed 2026-09-12. https://satohub.ai/numbers/x402-endpoints-that-answer

This page is refreshed daily. Citations include the date so a reader can tell which snapshot a claim came from.