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 means a probe received HTTP 402 with a parseable accepts array consistent with the catalog declaration. The probe uses the HTTP method the listing declares when that method is GET, POST, HEAD, or DELETE, and GET when the listing declares no method or a method outside that set. fail means two or more consecutive probes contradicted the catalog declaration (each with a recorded reason). unverified. unverified means vet402 does not have grounds to publish either pass or fail yet. It is not a failure and is never counted as one: it is an entry not yet reached by the rolling schedule, an entry whose failing probe has not met the publication gate, an entry recorded as path_template, or the remainder after the three above. The remainder includes a latest reason of rate_limited, tls, request_shape, or unsafe_target. It also includes a latest reason of method_undeclared, for which no request was sent before 2026-09-02, and body_over_cap, for which a 402 came back and the body was not read to the end. A listing that declares no HTTP method, or a method other than GET, POST, HEAD, or DELETE, is measured with GET, and two consecutive failures of that probe can be published as fail. A day on which vet402's own fetch was incomplete produces no delisting judgements at all.

Verify a payee·Get an API key