The x402 Observatory
This page lists live endpoint checks. Values here are measurements, not opinions.
pass 20,646(61.1%)fail 4,437(13.1%)unverified 8,719(25.8%)[receipts 2,732]
/api/v1/observatory/state. Select a legend entry to filter the table.1.Observed endpoints
2.Reading this table
Abstract
Every endpoint in the public x402 discovery catalog: is it still listed, and does its payment wall answer a valid 402 challenge when approached with the method it declares. The catalog is re-fetched daily; endpoints are probed on a rolling schedule, and each row shows when it was last probed. The L0 cell is the payment-wall measurement alone; the L1 cell counts real purchases that returned an on-chain receipt (settled / paid attempts) above the count that also returned a 2xx response (delivered), with every receipt listed on the endpoint's page. The two are never mixed. pass / fail / unverified are defined measurements, not opinions — definitions here. unverified is not a failure: it means we do not have grounds to publish either of the other two yet. Most often that is because the rolling schedule has not reached the endpoint, or a single failing probe has not met the publication gate; the entry declaring too little to check is one cause among several, and the current breakdown is counted out in the methodology.
Order. Endpoints with at least one settled L1 purchase first, then measured endpoints (pass / fail), then by observed call volume (catalog-reported, last 30 days). L1 is shown as delivered · settled / attempts for that endpoint; — means no purchase was attempted. settled is the transfer vet402 re-read on-chain; delivered is a settled attempt whose paid request also answered 2xx. A paid attempt that answered 4xx — settled, or refused with no settlement receipt — is published as inconclusive and is not counted against the seller: vet402 buys with no API key of the seller's and sends a POST body only when the seller declares one, so a 4xx can be vet402's own request being malformed. So is a 402 or 5xx from 2026-09-13 00:00 to 2026-09-15 23:49 UTC, when vet402's own payer wallet had run out of USDC. The endpoint's page shows those rows and the count (methodology §2). Per-endpoint counts use the same paid-attempt denominator as the totals reported by /api/v1/observatory/state. The [receipts] entry under Figure 1 keeps only rows with a receipt.
Snapshot line. fetched is the number of raw catalog items received across pages, counted before duplicate URLs collapse into one endpoint key; catalog is the total the catalog reports about itself. Fetched can exceed the catalog total for that reason, and a fetch below the total is incomplete: no delisting judgement is made on such a day. Endpoints on record (Figure 1) include delisted entries; the Catalog column says which are still listed. The active count under Figure 1 is a different figure from the catalog total on the snapshot line: it counts endpoint rows on record whose catalog status is still active. That status is set when a fetch lists the endpoint and flipped to delisted only by the daily diff against the previous day's snapshot on a complete fetch, so it is carried over from earlier days rather than re-read from the snapshot line, and the two need not agree.
Catalog is presence in the public discovery catalog: active means listed as of the latest snapshot; delisted means the entry was present on an earlier day and absent on a complete fetch — with the before/after recorded on the endpoint's page. L0 is the payment-wall measurement: pass — a probe using the declared method received HTTP 402 with a parseable accepts array consistent with the catalog declaration; fail — two or more consecutive probes contradicted that (each with a recorded reason); unverified — not enough declared to measure, or the evidence threshold is not yet met. A day on which our own fetch was incomplete produces no delisting judgements at all.