The x402 Observatory

This page lists live endpoint checks. Values here are measurements, not opinions.

1.Observed endpoints

→ 0 more columns

2.Reading this table

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 [settled on-chain] entry under Figure 1 lists the endpoints with at least one purchase settled on-chain, whether the transaction came from the seller's receipt or from vet402's own index. A receipt on these pages is the seller's own settlement 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.

Verify a payee·Get an API key