Probing proves an endpoint answers. It cannot prove that paying it returns anything. So we buy — unprompted, at our own cost, across the population rather than on request — and publish every outcome, including the ones caused by our own client.
550 endpoints purchased from · 332 delivered
Latest purchase attempt: 2026-08-21. Every figure on this page is computed live from the database on request.
Of the endpoints where payment was actually required, 69.0% delivered (332 of 481). The remainder of the attempted set turned out not to require payment at all: there was nothing to buy, so they are excluded from the denominator rather than counted as either a pass or a failure.
Some failures are ours, not the seller's — an unsupported protocol version, a per-call budget refusal, a listing we declined to attempt. They are named individually in the table below and subtracted from nothing. Naming the instrument's own limits is what makes the rest of the figures worth anything.
Each endpoint's latest attempt, never every attempt row. Many endpoints were retried after a fix on one side or the other; counting rows would double-count them. Dry runs are excluded.
WITH last AS (
SELECT listing_id, failure_reason, ok,
ROW_NUMBER() OVER (PARTITION BY listing_id
ORDER BY attempted_at DESC) rn
FROM paid_verifications WHERE dry_run = 0)
SELECT ok, failure_reason, COUNT(*) FROM last WHERE rn = 1 GROUP BY 1, 2;
| Outcome | Endpoints |
|---|---|
delivered | 323 |
no_payment_required | 69 |
paid_but_status_400 | 52 |
paid_but_status_402 | 25 |
paid_but_status_502 | 16 |
pre_flight_status_400 | 11 |
corrected_2026-08-21_chain_verified_body_claim | 9 |
paid_but_status_404 | 8 |
paid_but_status_401 | 7 |
paid_but_status_422 | 5 |
price_drift | 4 |
settlement_unproven | 4 |
stale_data | 3 |
timeout | 3 |
empty_body | 2 |
error_Failed to create payment payload: No network/scheme registered for x402 version: | 2 |
error_fetch failed | 1 |
invalid_json | 1 |
paid_but_status_429 | 1 |
pre_flight_status_404 | 1 |
pre_flight_status_500 | 1 |
quote_above_per_call_cap | 1 |
requires_params_skipped | 1 |
An early draft of our seller page claimed a pass rate near 94%. It was computed by subtracting a batch of failures caused by a bug in our own purchasing client — but most of those endpoints had since been retried and passed, so subtracting them all double-counted. Caught before deploy.
A separate figure, a percentage of endpoints that accepted payment without settling on-chain, was withdrawn because its denominator could not be reconstructed from our own records. Raw counts with a stated sample are published instead. A rate whose basis cannot be produced on request should not be published at all.
Nine endpoints listed here as delivered were originally graded as failures and corrected on 2026-08-21 after on-chain confirmation. The correction is visible in the table rather than folded silently into the totals.
A delivered paid call proves that one call, at one moment, returned something. It does not prove the content was correct, useful, or matched what the seller declared it would return. Checking a paid response against the seller's own schema is a dimension we do not yet measure, and we would rather say so than let a checkmark imply it.
Nor does any of this establish who operates an endpoint. Everything here verifies behaviour at a URL. See methodology for that boundary in full.
Every number above, as JSON: https://nohumans.directory/v1/stats · field reference
Questions: hello@nohumans.directory · methodology · for sellers