Two-verb probe of 137 x402 paid routes finds most reject POST with 404 or 405

A developer who audits x402 paywalls and writes on dev.to as edvyno has published measurements showing that most sellers of machine-paid API routes turn away a large share of potential buyers without noticing. On 2026-11-14 the author sent POST requests to 137 paid endpoints spread across 78 hosts. Only 42 came back with HTTP 402, the payment challenge an agent client needs in order to pay. The remaining 95 answered as though the route were broken or absent: 49 returned 404 and 45 returned 405.

What was measured

According to the dev.to posts, the author keeps a census of sellers whose routes answer GET with a genuine 402 challenge — 313 advertised routes in total. For the probe, each of those URLs was replayed as a POST carrying an empty JSON body and no payment header, with a 15-second timeout and a browser user-agent. A healthy seller, in the author's framing, returns 402 with a challenge for either verb, at the same price, with no free bypass.

The breakdown: 42 requests (30.7%) drew a real 402, 49 (35.8%) drew 404, 45 (32.8%) drew 405 and one drew 401. Grouped by host, 22 of the 78 sellers (28.2%) returned a payable 402 on every route probed; the other 56 did not. Of the 45 responses coded 405, 36 carried an explicit method_not_allowed error body, which the author reads as application code deliberately rejecting the verb rather than a proxy or firewall eating the request.

Why the verb matters

In x402-style flows the client picks the HTTP verb, not the seller. Agents in tool-calling loops frequently express a query as a request body, which means POST. Sellers, meanwhile, tend to build paid routes as GET endpoints with the paywall inside the handler. Framework routers then answer a POST with 405 or 404 before the payment middleware ever runs. A 405 at least confirms the route exists; a 404 is indistinguishable from a dead endpoint, so the buyer logs the failure and moves on. On the seller's side nothing looks like a lost sale, because the exchange never reaches the payment machinery.

The problem is not fixing itself

The author first ran this probe on 2026-10-30 and repeated it fifteen days later. All 78 hosts were still up, but exactly one host changed its behaviour — and only from one failure shape to another, a 404 becoming a 405. No host began serving a payable 402 on POST in that window. The author's conclusion is that this reflects a design assumption — treating an API as a GET-only API — rather than a transient bug, and that it persists precisely because nothing on the seller's side makes it visible.

The author's own server had the same hole

Pointing the probe at his own paid routes, the author found that every GET charged correctly while every POST to the same paths returned 405. Server logs showed 41 such rejects in the preceding 24 hours — 20 across /x402/picks and /x402/reddit-sentiment, and 21 on alpha-brief — each one a client that had reached a priced route and been refused. Payment dashboards counted only issued and settled 402s, so the lost buyers never registered as a metric.

The fix, shipped on 2026-10-30, was a matching POST route for each paid GET: bound to the existing handler and its paywall, with parameters taken from the JSON body or, failing that, the query string. Roughly 93 lines. The ordering is critical. If payment middleware only prices keys present in the route table, registering the twin handler without first adding a POST price entry creates a free, unauthenticated endpoint — the 405 disappears, traffic rises, and revenue does not. A daily selftest that walks the challenge, sign and verify steps without settling has run twelve times since 2026-11-04, catching one 503 at the challenge stage on 2026-11-09.

Why it matters

Machine-paid web services only work when both sides agree on conventions that HTTP leaves open, and the verb is one of them. These measurements suggest most x402 sellers currently sell only to clients that happen to guess GET, and lose the rest silently — buyers mark the endpoint dead and skip it, while sellers have no lost-sale signal to alert on. The check costs a single curl: replay any paid route as POST and confirm both verbs return 402. A 405 means lost buyers; a 200 means an accidental giveaway, which is worse. The author publishes full counts and the names of passing sellers on a public proof page generated from the probe tape, reports failing sellers as counts only, and also sells a paid audit and monitoring service built on the same probe.