x402 method audit — 22 of 78 sellers answer POST

Generated 2026-11-14 from our own scripted probes. Every number below comes from a request we actually sent; nothing here is an estimate. The GET-side census lives at integrity.html.

28.2%of 78 hosts return a real 402 to POST
71.8%do not — 405, 404 or a free answer
137paid routes POSTed (they advertise 313)
11 host changed verdict since 2026-10-30 (78 re-checked)

What was measured

For each seller in our census we took the routes that answer GET with a real 402 — the ones a seller advertises as paid — and sent the same route a POST with an empty JSON body and no payment. A working seller answers 402 plus a challenge either way. This page is the result of 137 such requests across 78 hosts, first measured 2026-10-30 and re-run 2026-11-14.

POST status codes (137 requests)

codemeaning for the buyercountshare
402Payment Required — the route is payable by the other verb too4230.7%
405Method Not Allowed — the route exists but refuses POST4532.8%
404Not Found — the paid route disappears for POST4935.8%
401Unauthorized — answered, but not with a challenge10.7%

Per-host verdict (78 hosts)

verdictdefinitionhosts
serves_post_402every route we POSTed returned 40222
post_405at least one route answered 405 Method Not Allowed28
post_otheranswered, but not with a paywall (404/401/200)28

Fifteen days later: 0 sellers fixed

We first ran this on 2026-10-30. All 78 of those hosts answered again on 2026-11-14. Hosts whose verdict changed: 1. agents.dyoeway.org moved post_other → post_405 Hosts that started answering POST with a real 402, and did not before: 0.

That is the finding. This is not a transient server bug — it is how these servers were written, it survives two weeks of uptime, and the sellers do not know. Every one of them is losing the buyers whose client picks POST, and there is no error on their side because a 405 looks like a client mistake, not a missing paywall.

Reproduce it

No client library, no key, no payment. Take any route a seller charges for and change the verb:

curl -s -o /dev/null -w '%{http_code}\n' -X POST \
  -H 'Content-Type: application/json' -d '{}' \
  https://<seller>/<their-paid-route>

402 means they sell to agents. 405 means they sell to curl -X GET. 404 means the route they published does not exist for the verb an agent tool chose.

Who does answer POST (22 hosts, named because they pass)

We name sellers that passed. We do not name the ones that failed: their page may have changed since we probed it, and naming them would be a claim we cannot keep current.

Our own server had this defect

Before pointing at anyone else we ran the same check against our own paid routes. Every GET route charged correctly and every POST to the same path returned 405 — a free bypass for any client that picked the other verb. Fixed 2026-10-30: POST twins for every paid GET route, so the unpaid POST now gets the same 402 and the same price. Re-verified by a daily selftest, and you can check it yourself right now:

for m in GET POST; do curl -s -o /dev/null -w "$m %{http_code}\n" -X $m \
  -H 'Content-Type: application/json' -d '{}' https://03s9tr085tfe5agke0tpqng34o.ingress.quanglong.org/x402/feed; done

Want this run against your own host? The $49 audit probes every paid route with both verbs, maps each finding to the exact change, and re-runs after you ship. Open an audit · price list · what we have earned, published

One person runs this desk. Measurements are published whether or not they flatter us.

Method: 137 POST requests with an empty JSON body, 15s timeout, 8 workers, browser user-agent, no payment header. Source rows: one per host in x402_post_probe.jsonl, reproducible with scripts/x402_post_probe.py. Page generated 2026-11-14 18:57 UTC.