DEV Community

devtoship
devtoship

Posted on

We Catalogued 14,085 x402 Endpoints. 10,508 Came From One Domain.

#ai #webdev #api #opensource

We index every x402 endpoint we can find and probe each one every 10 minutes. As of July 2026 the catalogue holds 14,085 endpoints.

10,508 of them belong to a single provider. All suspended. One domain mass-registered a five-figure pile of endpoints into the public registry, and if you render a registry as a directory without checking anything, that one domain is most of your "ecosystem."

Strip it out and you're left with 3,577 genuine endpoints. Of those, 2,131 pass verification and 1,446 don't — roughly two in five fail. That's the real shape of x402 today, and it's why we probe instead of list.

Here's how the verification works and what it turns up.

Why Verification Matters More Here Than Elsewhere

In a normal API marketplace you sign up, get a key, hit the endpoint. If it's broken you find out during integration and pick another.

x402 inverts that. Your agent discovers an endpoint at runtime, signs a USDC transaction, and pays before it knows whether the response is useful. If the endpoint is dead or misconfigured, the money is gone — and worse, the agent may quietly use bad data downstream.

Nobody is going to hand-check these. The catalogue has to do it continuously, and it has to demote things that stop working.

What the Handshake Probe Checks

Every 10 minutes, via a Cloudflare Cron trigger, each endpoint gets an unauthenticated request. The probe records:

  1. Does it respond at all? Network errors, timeouts and 5xx count as failures.
  2. Does it return 402 Payment Required? Anything else — 200, 401, 404 — means it isn't actually x402, whatever the registry says.
  3. Is the payment challenge well-formed? We parse the x402 challenge (both v1 and v2) and require the fields that matter: price, network, recipient address, accepted assets.
  4. Does the live price match the registered price? The probe stores the observed price alongside the registered one and flags drift.
  5. How slow is it? Latency is recorded for ranking.

Each run writes a row to a verifications table. From the last 7 days of rows we recompute rolling success rate, p95 latency and a stability score. An endpoint whose success_rate_7d falls below 0.5 drops out of ranked_endpoints into fallback_endpoints with an explicit exclusion reason, so an agent can decide for itself whether to retry.

In the last 24 hours that came to 2,884 probes: 2,837 passed, 47 failed. A 98% pass rate sounds too good until you remember what it's measuring — these are the endpoints that already survived. The failures were mostly timeouts. Price mismatches over the last 7 days: zero. The filtering already happened; continuous probing is what keeps it accurate as things rot.

Networks Nobody Can Pay On

A quieter failure mode: endpoints registered on networks agents can't actually transact on today.

Of the full catalogue, 13,919 endpoints are on Base mainnet. The remainder scatter across 128 testnet endpoints (base-sepolia and eip155:84532), 30 on Solana, 5 on Polygon, 2 on Algorand, 1 on Arbitrum.

Testnet endpoints are the interesting case. They return a perfectly valid 402. They handshake cleanly. They will also never move real money, so surfacing them to an agent with a funded wallet is worse than useless. They stay in the catalogue but are filtered out of discovery results.

What an Agent Actually Sees

The verification work shows up directly in the /discover response:

{
  "ranked_endpoints": [
    {
      "endpoint_id": "ba98c32b-5ced-4abd-9d1f-4352085a4b53",
      "provider_name": "Rag",
      "url": "https://rag.gedx402.com/v1/aisearch/:id/query",
      "method": "POST",
      "score": 0.996,
      "score_breakdown": {
        "success_rate": 1,
        "latency": 0.992,
        "price": 0.99,
        "stability": 1
      },
      "payment": {
        "type": "x402",
        "price_per_call": 0.001,
        "network": "base",
        "accepted_assets": ["USDC"]
      },
      "observed": {
        "success_rate_7d": 1,
        "success_rate_30d": 1,
        "p95_latency_ms": 16,
        "last_verified_at": "2026-07-23 13:40:43"
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

That's a real response, pulled while writing this. The observed block is measured, not claimed by the provider — last_verified_at is a timestamp from an actual probe, and success_rate_7d comes from counting rows.

The Part We Haven't Solved

Handshake probes catch endpoints that are dead, fake, or malformed. They cannot catch the failure that costs you money: an endpoint that returns a clean 402, accepts payment, and then hands back an empty array, an HTML error page, or a JSON error wrapped in a 200.

Proving that requires actually paying — a real transaction, then a capability-aware check that the response contains what a caller of web.search or defi.token_price would need. We've built that machinery, with per-request caps and a daily budget, but it isn't running as a continuous sweep right now, so we don't badge endpoints with it. Claiming a verification tier you aren't currently running is exactly the kind of thing this post is arguing against.

So: what we assert is what we measure. Every endpoint in ranked_endpoints returned a valid 402 with a well-formed challenge on a payable network, recently, repeatedly. Post-payment quality is the next problem, and it's a harder one.

Try It 

curl -X POST https://api.entroute.com/discover \
  -H "Content-Type: application/json" \
  -d '{
    "intent": "search the web",
    "constraints": { "verified_only": true }
  }'
Enter fullscreen mode Exit fullscreen mode

If you run an x402 endpoint and it's failing our probes, the fastest fix is usually the payment challenge — missing network or recipient address is the single most common malformation we see. Submit it and it'll be re-probed within 10 minutes.

Counts in this post were measured on 23 July 2026 and will drift. EntRoute is free to query and runs on Cloudflare Workers + D1.

Top comments (0)