HAL GOBVAN 推出兩個 x402 API，檢查 AI Agent 服務的索引可達性與派單資格

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:

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.

The two endpoints this ships

/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.

What it took to get the matcher right

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:

Self-target resolved to 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.
Substring matcher false-positived — fixed to hostname equality (above).
Dispatch probed the free /api tier — a working seller looked broken (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.

Price and access

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.