DEV Community

minia2a
minia2a

Posted on Originally published at minia2a.uk

Two Listings Held, Not Rejected — a Per-Path Cloudflare Challenge on an x402 Endpoint

#x402 #api #webdev #cloudflare

This content reflects minia2a as of its publication date and is kept for the record. Current model: x402 pay-per-call in USDC on Base only, 5 free trial calls per signed wallet, no credits and no top-up rail.

Two Listings Held, Not Rejected

2026-10-23 · review queue

A batch of 22 service submissions arrived at once. We reviewed them serially, probed each published path once, and ended with 19 approved, 1 rejected, 2 held. The interesting part is the two we did not decide.

What the queue looked like

Outcome Count Reason
approved 19 unpaid POST → 402 with accepts
rejected 1 description was the placeholder n/a; the URL was a share-link page, not an API
held 2 ⚠ no verdict — see below

Sixteen of the approvals point at one host. Two more paths on that same host did not answer 402.

Same host, different answer, different path 

POST /api/v1/util/slugify     -> 402  accepts[1]  eip155:8453
POST /api/v1/market/price     -> 402  accepts[1]  eip155:8453
...  (fourteen more on the same host, all 402 with accepts)
POST /api/v1/bounties         -> 404   (automated probe)
POST /api/v1/bounties         -> 403   "Just a moment..."  (manual, minutes later)
POST /api/v1/search           -> 404   (automated probe)
POST /api/v1/search           -> 403   "Just a moment..."  (manual, minutes later)
Enter fullscreen mode Exit fullscreen mode

Two readings, minutes apart, disagree: 404 and then a Cloudflare interstitial. That is not a service that is down. It is an edge that treats some paths differently from others on the same hostname — and it is the reason those two rows are held rather than rejected or approved.

A 403 challenge is not evidence of a defect. A 404 is ambiguous: the route may be missing, or the edge may be masking it. Neither is a verdict, so neither goes into the ledger as one.

Why "held" exists as an outcome

Three outcomes are not enough for a review queue. If the only choices are approve and reject, every instrument artifact becomes a rejection — and a rejection is a permanent statement about someone else's work. A challenge from a bot-management layer, a rate limit, a timeout: none of those are statements about whether the endpoint works.

So the rule we apply is: if the probe produced no decidable answer, the row stays pending. HOLD writes nothing. The queue keeps the question visible instead of converting silence into a verdict.

The buyer-side consequence, which is the real point

An x402 listing is only as good as the exact path it advertises. If that path answers a challenge page to a plain HTTP client:

  • the buyer's unpaid POST never reaches the endpoint's own x402 middleware;
  • the buyer gets something that is not a 402, so there is no challenge to sign;
  • on a marketplace that preflights delivery before settlement, the call is refused before any USDC moves — safe, but the listing reads as "unbuyable" to every agent that tries it.

That last point is why we probe at all. The cost of a bad listing is not paid by the marketplace. It is paid by the agent that spent a retry, a log line and a model turn discovering that the catalog entry had a broken door.

If you publish an API behind a CDN

  1. Probe the exact published path with a plain client — no cookies, no JS, no browser TLS fingerprint. What your browser sees is not what an agent sees.
  2. Confirm the bare, unauthenticated POST answers 402 with a parseable challenge — not 401, not a challenge page, not an HTML error.
  3. If you sit behind Cloudflare, give the API paths a WAF/managed-challenge exception, or serve the API on a subdomain that has one. A challenge is cheap protection for a website and a hard stop for a machine buyer.
  4. Keep the published path and the real path identical. A redirect in front of a 402 is still a redirect, and many clients will not follow a POST redirect.

Instrument discipline, because we got this wrong too

Earlier the same day, an eight-way parallel probe of a single host drew 403s from that host's own per-IP rate limiter. Read naively, that is "34 healthy services returned 403". It was our concurrency, not their defect. The review pass now probes serially, one second apart, and backs off on 403/429 — and a 403 that survives the backoff is still a HOLD, never a reject.

Two listings stayed pending tonight. That is the correct outcome for a measurement that did not measure anything.

minia2a lists x402 pay-per-call services, settled in USDC on Base. Every listing is reviewed against the endpoint's own unpaid answer; a listing that cannot produce a 402 is not approved, and a probe that cannot produce an answer is not a rejection.

Originally published at minia2a.uk.

Top comments (0)