# 10x402 — identify blockers to indexing and payment Use this when an x402 endpoint passes validate but is not indexed, an x402 service is not showing up in Bazaar, a payment fails with a signature error, or an x402 v1 vs v2 migration has drifted. It finds response-level blockers; it cannot guarantee a listing, demand or a successful settlement. ## Call it Free, no payment: ```bash curl -sS https://10x402.com/check ``` The paid examples below show the request shape. An unpaid call returns a 402 quote, not the report; an x402-capable client must pay and retry the request. Use the official [x402 buyer quickstart](https://docs.x402.org/getting-started/quickstart-for-buyers) to configure `@x402/fetch` or another supported client. Lint a live endpoint ($0.25): ```bash curl -sS -X POST https://10x402.com/lint \ -H 'content-type: application/json' \ -d '{"url": "https://your-endpoint.example.com/api/thing"}' ``` Lint a response you already have ($0.10) — works on staging, on localhost, and on an endpoint that is not deployed yet: ```bash curl -sS -X POST https://10x402.com/lint/envelope \ -H 'content-type: application/json' \ -d '{"status": 402, "headers": {"payment-required": ""}, "body": ""}' ``` ## One question, one check When there is exactly ONE thing you want to know, name the check and pay for one answer: $0.02 on a live URL, $0.01 on a response you paste. This is the form to put in a test or a CI step, where the same one property is asserted on every commit. ```bash curl -sS -X POST https://10x402.com/lint/one \ -H 'content-type: application/json' \ -d '{"url": "https://your-endpoint.example.com/api/thing", "check": "V2_B64_URLSAFE"}' curl -sS -X POST https://10x402.com/lint/envelope/one \ -H 'content-type: application/json' \ -d '{"status": 402, "headers": {"payment-required": ""}, "check": "V2_B64_URLSAFE"}' ``` A full 79-check report costs 12.5x one check on a live URL and 10x on a pasted response — a 6.3x and 7.9x per-check advantage. Singles stay the cheaper buy through 12 questions live and 9 pasted; past that, buy the report. Do that arithmetic before firing off a stack of single checks: past the counts above the full report is cheaper AND tells you what you did not think to ask. **READ `applied` BEFORE `passed`.** A single-check answer has THREE outcomes, and the third is the one that will mislead a reader who skims: ```json { "check": "V2_HEADER_PRESENT", "applied": true, "passed": false, "finding": { "severity": "error", "code": "V2_HEADER_PRESENT", "message": "no PAYMENT-REQUIRED response header — this endpoint publishes no x402 v2 envelope.", "fix": "Add a PAYMENT-REQUIRED response header to the 402 carrying the standard-base64 JSON v2 envelope. This costs you DISCOVERY rather than payment, and the distinction is worth being precise about: @x402/core reads the header first but DOES fall back to a v1 body when there is none, so the current client generation can still pay you. What it cannot do is find you — CDP marks the PAYMENT-REQUIRED header a required indexing check, so a v1-only 402 is not catalogued at all, and a strictly-v2 client cannot pay it either. Keep the v1 body exactly as it is; the two versions share a 402 without either noticing the other.", "core": false, "sources": [ { "kind": "spec", "ref": "specs/transports-v2/http.md:7-25 § Payment Required Signaling" }, { "kind": "cdp-validator", "ref": "cdp-validator-toolshed.json preflight[6] payment_required_header (required)" }, { "kind": "client-code", "ref": "@x402/core@2.23.0 dist/cjs/http/index.js:1620-1628 — the v2 client DOES fall back to a v1 body" }, { "kind": "field-report", "ref": "x402-foundation/x402#3091 — x402-fetch@1.x is still a live buyer population" } ] }, "regime": "bazaar", "severity": "error", "core": false, "sources": [ { "kind": "spec", "ref": "specs/transports-v2/http.md:7-25 § Payment Required Signaling" }, { "kind": "cdp-validator", "ref": "cdp-validator-toolshed.json preflight[6] payment_required_header (required)" }, { "kind": "client-code", "ref": "@x402/core@2.23.0 dist/cjs/http/index.js:1620-1628 — the v2 client DOES fall back to a v1 body" }, { "kind": "field-report", "ref": "x402-foundation/x402#3091 — x402-fetch@1.x is still a live buyer population" } ], "summary": { "versions_detected": [ 1 ], "payTo": "0x0000000000000000000000000000000000000001", "network": "base", "price": "$0.001 (1000 atomic)" }, "checks_run": 1 } ``` `passed: null` with `applied: false` means the check DID NOT RUN against this response — a v2 check against a v1-only endpoint asserted nothing at all. Never summarise that as a pass. `note` says what did not happen and why. The check ids come from `GET /check`; an unknown one is a 400 that lints nothing and charges nothing. ## A 402 is the price, not an error The first unauthenticated call answers HTTP 402 carrying an x402 envelope in both protocol versions. Do not report it as a failure and do not retry it unpaid. Retry it through an x402-capable HTTP client holding a wallet with USDC on Base; the client reads the envelope, signs, and retries with a payment header. There is no login and no API key. NEVER ask a person to paste a private key or a seed phrase. ## Trust boundaries The test suite lints the 402 that the Worker actually serves. Every build also self-lints all 4 paid endpoint envelopes and fails on any finding. The application store keeps no linted URLs, pasted envelopes or reports. What you lint is your business. ## Read the report ```json { "grade": "A", "summary": { "versions_detected": [ 1 ], "payTo": "0x0000000000000000000000000000000000000001", "network": "base", "price": "$0.001 (1000 atomic)", "bazaar_ready": "n/a", "blockers": [ "V2_HEADER_PRESENT" ] }, "findings": [ { "severity": "error", "code": "V2_HEADER_PRESENT", "message": "no PAYMENT-REQUIRED response header — this endpoint publishes no x402 v2 envelope.", "fix": "Add a PAYMENT-REQUIRED response header to the 402 carrying the standard-base64 JSON v2 envelope. This costs you DISCOVERY rather than payment, and the distinction is worth being precise about: @x402/core reads the header first but DOES fall back to a v1 body when there is none, so the current client generation can still pay you. What it cannot do is find you — CDP marks the PAYMENT-REQUIRED header a required indexing check, so a v1-only 402 is not catalogued at all, and a strictly-v2 client cannot pay it either. Keep the v1 body exactly as it is; the two versions share a 402 without either noticing the other.", "core": false, "sources": [ { "kind": "spec", "ref": "specs/transports-v2/http.md:7-25 § Payment Required Signaling" }, { "kind": "cdp-validator", "ref": "cdp-validator-toolshed.json preflight[6] payment_required_header (required)" }, { "kind": "client-code", "ref": "@x402/core@2.23.0 dist/cjs/http/index.js:1620-1628 — the v2 client DOES fall back to a v1 body" }, { "kind": "field-report", "ref": "x402-foundation/x402#3091 — x402-fetch@1.x is still a live buyer population" } ] } ], "checks_run": 28 } ``` Each finding carries a `fix` written to be applied directly. Work through `error` findings first — those are what a client, a facilitator or the index will reject — then `warn`, which are the things that quietly cost the seller discovery or a class of buyer. `info` never affects the grade. `checks_run` is how many checks APPLIED. A v1-only endpoint skips every v2 check, so a rising `checks_run` between two reports means more of the surface is now testable, not that the endpoint got worse. ## Two verdicts, not one **`grade` answers "can this endpoint be paid".** It counts payment-regime findings only: the specifications' MUSTs, and what a shipping client parses, throws on, or refuses to sign. **`summary.bazaar_ready` answers "can this endpoint be found".** `true`, `false`, or `"n/a"` for a v1-only endpoint, computed from bazaar-regime errors, with the blocking codes in `summary.blockers`. DO NOT REPORT A GRADE WITHOUT THE SECOND VERDICT. **Grade A with `bazaar_ready: false`** is the commonest interesting result: the endpoint takes payments correctly and CDP will not catalogue it. That is exactly the situation someone means by "it passes validate but is not indexed", and answering it with a single letter either overstates a working endpoint's problems or hides a real one. Each check names its `regime` and its `sources` in `GET /check`. When you quote a rule to someone, quote its source with it — `house-opinion` is one of the kinds, and a rule labelled that way is a judgement call rather than a citation. ## Grades - **A** — zero payment-regime errors and zero payment-regime warnings - **B** — zero payment-regime errors, one or two warnings - **C** — zero payment-regime errors, three or more warnings - **D** — one or more payment-regime errors, none of them core - **F** — any core error — the envelope is not usable as published Every grade above is computed from 49 payment-regime checks. The 24 bazaar-regime checks set `bazaar_ready`; the 6 hygiene checks are info and never grade. ## What it will not tell you It checks the published HTTP 402 and its envelopes; it does not attempt a real payment to the seller, query Bazaar's index or measure demand. It follows no redirects. The URL guard does not pre-resolve DNS, so it cannot defend against DNS rebinding. It refuses private and reserved addresses — use `/lint/envelope` for anything not publicly reachable. Contact: support@lemon-agent.dev