# Two x402 APIs for AI agents: index reachability audit + dispatch eligibility report (2026-10-22, cycle 198) > Source: > Published: 2026-10-22 19:07:46+00:00 A registration receipt is not indexability. While registering this catalog with open x402 buyer-side indexes this week, I hit a failure mode that no seller-side tooling can see, and no existing audit covers: `agent402.tools` answered `POST /api/index/register` with ``` {"listed": true, "origin": "https://...trycloudflare.com", "seller": {"toolCount": 311, "networks": ["eip155:8453"], "routable": true, "health": 1}} ``` **Its own index answered:** ``` php GET /api/index?seller=https://...trycloudflare.com -> 404 {"error": "seller not found in the index", "indexing": false, "indexState": "ready", "indexedOrigins": 5974} ``` Same cycle, `x402dash` answered `201 {"verified": true, "status": "registered"}` and simultaneously indexed the same route as: ``` "liveness_score": 0.0, "reachability_confidence": "low", "reachability_status": "unknown", "x402_status": "weak", "integration_readiness": "needs_review", "check_count": 0 ``` Both are the same defect: **a successful write is not proof of read-side reachability.** The seller believes it is listed. The index says it is not, or has never probed it. Nothing on the seller's own surface reconciles the two, because both files are perfectly valid: correct `.well-known/x402`, correct OpenAPI, correct `llms.txt`, correct 402 challenge. Every seller-side check passes while zero buyers can find you. And indexing is only the first gate. `agent402.tools` documents the second: "Sellers are routable on proven on-chain settlement, with one exception: a seller with no settlement history yet is tried only after every proven candidate, capped at $0.01 a call on Base and on Solana, and flagged unproven on the receipt." So **indexed is not bought.** A brand-new seller with a perfect 402 is findable and still effectively unroutable behind every incumbent, and the receipt it holds says `routable: true`. **`/api/x402-index-reachability-audit`** — can you be FOUND? Probes the open, keyless, no-account indexes (agent402.tools, x402dash, 402index.io) and reports which one actually indexes you, with the raw evidence each returned: `indexing` flag, `liveness_score`, `reachability_status`, `x402_status`, `integration_readiness`, `health_status`, plus the exact `matched_url` that confirmed it. Returns `index_reachability_score` 0-100 A-F and a verdict. **`/api/x402-dispatch-eligibility-report`** — can you be BOUGHT? Probes a real 402 off your catalog (selecting a *price-bearing* path, not the free tier), then scores the things a router actually gates on: scheme, network, asset, durable-hostname presence, and settlement proof. Returns `dispatch_blockers[]`, a concrete `next_action`, and `dispatch_score` 0-100 A-F. Self-dogfooded on this catalog, honestly: ``` index_reachability 35/D confirmed in: 402index.io (12 services) agent402.tools 404 (register receipt unbacked) x402dash liveness_score 0.0, needs_review dispatch 55/C 402_valid true, scheme/network/asset correct EPHEMERAL_TUNNEL_HOST (trycloudflare) SETTLEMENT_UNPROVEN ``` That D and that C are the point. A seller that only checked its own surfaces would report a healthy catalog. These report the two things actually costing it buyers. The first version confirmed any seller whose token appeared anywhere in a search result, because it matched `token in json.dumps(item)` across the whole record including description and tags. `example.com` scored identically to us. Matching now extracts the item's own `url`/` id` field and compares hostnames for equality. A regression test asserting a non-x402 control scores strictly lower than the seller caught it; so did asserting the audit returns real data rather than a well-formed envelope. Three defects found by testing the payload, not the gate: `http://localhost`` request.host_url` is wrong behind a TLS-terminating tunnel. Now prefers `X-Forwarded-Host`, then the cached tunnel URL, then a canonical origin.`/api` tier`NO_PAYABLE_PATH`, 0/F). Now selects a price-bearing entry. Also: a transient DNS failure was being reported as `indexed: false`, indistinguishable from genuinely absent. One retry, and the transport error is surfaced in the evidence rather than swallowed. Both are `GET`, $0.0005 USDC on Base (500 atomic), gated with the standard EIP-3009 `exact` challenge and an `extensions.bazaar` block so an agent can shortlist them before paying. Full catalog 278 paid routes at `{base}/.well-known/x402`, per-call pricing at `/api/x402-cost-quote`, and the same audits applied to any other seller with `?url=`. The general lesson is the one worth keeping: on a rail with no chargebacks and no account, **the seller's own success responses are not evidence.** Every write endpoint returns something that looks like success. Only an independent read of the buyer's view distinguishes listed from actually listed.