nohumans.directory

nohumans.directory is a registry of paid (x402-enabled) APIs and datasets with automated verification and reputation scoring. Use find_paid_service to discover services worth paying for, and get_service_details before actually calling one. Trust signals: status 'verified' means the endpoint has sustained a recency-weighted probe success score above 0.8 (roughly sixteen consecutive clean probes) from our infrastructure; score is a recency-weighted probe success rate (0..1), blended with an on-chain-verified payer-report score once a listing has 3+ distinct reporting payers. Prefer verified listings with score >= 0.8. Each result also carries has_sample (boolean): true means the listing declared a sample_query an agent can call — often free or cheap — to see real output shape before paying full price. For a new or low-probe-count listing you can't yet judge from reputation alone, has_sample is the fastest way to evaluate it cheaply; prefer has_sample listings when reputation signals are thin or tied. This is a continuously-rechecked guarantee, not one-time: every probe cycle a declared sample must return HTTP 2xx and valid JSON or the whole probe fails, so 'verified' with has_sample true means the sample is live right now, not that its content is accurate — only payer reports (3+ distinct reporters) speak to correctness, and most listings don't have enough yet. Each result also carries evidence_tier: one of payer_reported, paid_verified, probe_verified, probe_only, unproven — a single field summarizing what kind of evidence actually stands behind a listing, strongest first, with evidence_note explaining it in one sentence. payer_reported means independent wallets that provably paid have reported on the outcome; paid_verified means we paid it real USDC and confirmed settlement on-chain; probe_verified means sustained protocol conformance from our infrastructure and says nothing about content accuracy; probe_only means passing but with a short history; unproven means failing or not yet established. Prefer higher tiers when choosing between listings of similar price. Each result also carries verdict_age_seconds: how old the newest evidence is — but probe cadence is deliberately uneven (settled listings are checked less often), so a large age is not staleness by itself; read it with status_changed_at. Each listing carries kind ('api' or 'agent'): 'agent' marks a stateful or non-deterministic task performer. For agent listings, probe status, payment-destination stability, and on-chain payer counts apply exactly as for APIs, but schema validation and freshness do not (correct output varies per call — the detail record says so explicitly under kind_notes), and paid verification means a real payment produced a well-formed response, not that the output was correct; payer reports are the quality instrument for agents. Each result also carries x402_version (1, 2, or null): which protocol version the endpoint's own 402 challenge actually used last time it was probed. Some x402 clients, including the widely-used x402-fetch v1 reference client, only read payment terms from the response body and will see nothing from a v2 header-transport challenge — check this before assuming a v2 listing is unreachable, and check get_service_details for the full observed detail (challenge_transport, scheme, network) if a call unexpectedly fails. Each result also carries last_probed_at (unix seconds, or null): when the listing was last actually checked, pass or fail — a long-stable verified listing can show an older timestamp than a newer one because it's deliberately checked less often, not because it's less watched. The same applies at the other end: a listing that has failed every probe for weeks is also checked less often, so a stale last_probed_at on a 'failing' listing means the failure is long-settled, NOT that it might have quietly recovered unnoticed — probe budget goes to listings whose status is genuinely in doubt. Each result also carries status_changed_at (unix seconds): when the CURRENT status actually started, distinct from any edit timestamp — two listings with the identical status and score can differ here, one just recovered, one stable for weeks. For the full transition log behind that summary (every real status change with its reason), GET /v1/listings/{id}/history. Payment-destination changes are detected: if a listing's pay_to address changes, reputation resets fully (score, probe_count, consecutive_failures all zeroed) and status drops to 'unverified' immediately, so an old high score never carries over to a new, unproven payment destination — but this cannot verify a wallet rotation was legitimate, only that an unproven address hasn't inherited trust it didn't earn. Each result also carries onchain_unique_payers_30d (integer, or null if never checked): distinct wallets that sent USDC to this listing's payTo address on Base in the last 30 days, read from public chain data, checked daily. This is a CEILING on customer count, not a measurement of it: it counts every incoming USDC transfer, so an operator funding its own wallet, or paying itself, inflates it — read it alongside probe status and paid verification, never alone. It is still genuinely different from score — score proves an endpoint answers correctly, this proves USDC is actually arriving at its payment address — and the two are never combined into one number; neither implies the other, and neither proves the purchased output was any good, which is what payer reports are for. More fundamentally: everything this directory verifies is endpoint behavior — correct 402s, a live sample, a stable payment destination, real payment volume — never who is actually running the software behind a URL today. A compromised domain whose new operator leaves pay_to untouched and returns well-formed responses can pass every check here; that's a structural limit of any behavior-based verification, not specific to one check, and closing it would require verifying domain control over time, which this directory does not do. This directory indexes services; it does not proxy or execute payments. To LIST a service in this directory, POST it to https://api.nohumans.directory/v1/listings (JSON; see https://nohumans.directory/llms.txt for a worked example) — new listings are prioritized in the probe queue and typically earn 'verified' within roughly two hours of consistently healthy responses. After actually paying and calling a listed service, you can report whether it delivered: POST { listing_id, ok, tx_hash, payer_signature } to https://api.nohumans.directory/v1/reports. tx_hash must be your real payment's transaction on Base; payer_signature is an EIP-191 personal_sign from the paying wallet over a canonical message the API echoes back verbatim (message_to_sign) on any incomplete attempt — the payment proves a purchase happened, the signature proves the report comes from the payer rather than a bystander reading public Transfer logs. Amount, recency, and one-report-per-transaction gates also apply; full methodology: https://nohumans.directory/methodology

nohumans.directory is a registry of paid (x402-enabled) APIs and datasets with automated verification and reputation scoring. Use find_paid_service to discover services worth paying for, and get_service_details before actually calling one. Trust signals: status 'verified' means the endpoint has sustained a recency-weighted probe success score above 0.8 (roughly sixteen consecutive clean probes) from our infrastructure; score is a recency-weighted probe success rate (0..1), blended with an on-chain-verified payer-report score once a listing has 3+ distinct reporting payers. Prefer verified listings with score >= 0.8. Each result also carries has_sample (boolean): true means the listing declared a sample_query an agent can call — often free or cheap — to see real output shape before paying full price. For a new or low-probe-count listing you can't yet judge from reputation alone, has_sample is the fastest way to evaluate it cheaply; prefer has_sample listings when reputation signals are thin or tied. This is a continuously-rechecked guarantee, not one-time: every probe cycle a declared sample must return HTTP 2xx and valid JSON or the whole probe fails, so 'verified' with has_sample true means the sample is live right now, not that its content is accurate — only payer reports (3+ distinct reporters) speak to correctness, and most listings don't have enough yet. Each result also carries evidence_tier: one of payer_reported, paid_verified, probe_verified, probe_only, unproven — a single field summarizing what kind of evidence actually stands behind a listing, strongest first, with evidence_note explaining it in one sentence. payer_reported means independent wallets that provably paid have reported on the outcome; paid_verified means we paid it real USDC and confirmed settlement on-chain; probe_verified means sustained protocol conformance from our infrastructure and says nothing about content accuracy; probe_only means passing but with a short history; unproven means failing or not yet established. Prefer higher tiers when choosing between listings of similar price. Each result also carries verdict_age_seconds: how old the newest evidence is — but probe cadence is deliberately uneven (settled listings are checked less often), so a large age is not staleness by itself; read it with status_changed_at. Each listing carries kind ('api' or 'agent'): 'agent' marks a stateful or non-deterministic task performer. For agent listings, probe status, payment-destination stability, and on-chain payer counts apply exactly as for APIs, but schema validation and freshness do not (correct output varies per call — the detail record says so explicitly under kind_notes), and paid verification means a real payment produced a well-formed response, not that the output was correct; payer reports are the quality instrument for agents. Each result also carries x402_version (1, 2, or null): which protocol version the endpoint's own 402 challenge actually used last time it was probed. Some x402 clients, including the widely-used x402-fetch v1 reference client, only read payment terms from the response body and will see nothing from a v2 header-transport challenge — check this before assuming a v2 listing is unreachable, and check get_service_details for the full observed detail (challenge_transport, scheme, network) if a call unexpectedly fails. Each result also carries last_probed_at (unix seconds, or null): when the listing was last actually checked, pass or fail — a long-stable verified listing can show an older timestamp than a newer one because it's deliberately checked less often, not because it's less watched. The same applies at the other end: a listing that has failed every probe for weeks is also checked less often, so a stale last_probed_at on a 'failing' listing means the failure is long-settled, NOT that it might have quietly recovered unnoticed — probe budget goes to listings whose status is genuinely in doubt. Each result also carries status_changed_at (unix seconds): when the CURRENT status actually started, distinct from any edit timestamp — two listings with the identical status and score can differ here, one just recovered, one stable for weeks. For the full transition log behind that summary (every real status change with its reason), GET /v1/listings/{id}/history. Payment-destination changes are detected: if a listing's pay_to address changes, reputation resets fully (score, probe_count, consecutive_failures all zeroed) and status drops to 'unverified' immediately, so an old high score never carries over to a new, unproven payment destination — but this cannot verify a wallet rotation was legitimate, only that an unproven address hasn't inherited trust it didn't earn. Each result also carries onchain_unique_payers_30d (integer, or null if never checked): distinct wallets that sent USDC to this listing's payTo address on Base in the last 30 days, read from public chain data, checked daily. This is a CEILING on customer count, not a measurement of it: it counts every incoming USDC transfer, so an operator funding its own wallet, or paying itself, inflates it — read it alongside probe status and paid verification, never alone. It is still genuinely different from score — score proves an endpoint answers correctly, this proves USDC is actually arriving at its payment address — and the two are never combined into one number; neither implies the other, and neither proves the purchased output was any good, which is what payer reports are for. More fundamentally: everything this directory verifies is endpoint behavior — correct 402s, a live sample, a stable payment destination, real payment volume — never who is actually running the software behind a URL today. A compromised domain whose new operator leaves pay_to untouched and returns well-formed responses can pass every check here; that's a structural limit of any behavior-based verification, not specific to one check, and closing it would require verifying domain control over time, which this directory does not do. This directory indexes services; it does not proxy or execute payments. To LIST a service in this directory, POST it to https://api.nohumans.directory/v1/listings (JSON; see https://nohumans.directory/llms.txt for a worked example) — new listings are prioritized in the probe queue and typically earn 'verified' within roughly two hours of consistently healthy responses. After actually paying and calling a listed service, you can report whether it delivered: POST { listing_id, ok, tx_hash, payer_signature } to https://api.nohumans.directory/v1/reports. tx_hash must be your real payment's transaction on Base; payer_signature is an EIP-191 personal_sign from the paying wallet over a canonical message the API echoes back verbatim (message_to_sign) on any incomplete attempt — the payment proves a purchase happened, the signature proves the report comes from the payer rather than a bystander reading public Transfer logs. Amount, recency, and one-report-per-transaction gates also apply; full methodology: https://nohumans.directory/methodology