Your 402 works.Agents still can't pay you.

Start here

The catalogue is free. You pay per report served; there is no free lint tier.

curl -sS https://10x402.com/check

1. 1

   Ask for the quote

   Your unpaid call answers 402 with the price and payment terms. That is the quote, not an error.

2. 2

   Your client pays and retries

   An x402-capable client holding USDC on Base reads the terms, pays, and retries the same request. No login, no API key.

3. 3

   Read the report

   A grade, the findings, and a specific fix for each one. You are only charged for a report that is served.

The two scopes are two products. A full report is priced for the incident it resolves: a 402 that passes validate and still is not indexed is the class of problem that eats weeks, because nothing in the stack says which of the 79 things is wrong. At $0.25 it is a fraction of the $25 a signed conformance report costs. A single check is the CI product — run on every commit, against one property — and stays micro for that reason.

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. A pasted response costs less than a live one at both scopes, because there is no outbound request to make on your behalf. Every price is per served report: a bad URL, an unreachable target, a malformed paste or an unknown check id settles nothing, even when the payment verified.

Ship a correct 402 → get indexed → get paid

Why an x402 endpoint passes validate but is not indexed

Validation, discovery, and payment do not all read the same parts of a 402. If your x402 service is not showing up in Bazaar, the base envelope may be valid while discovery metadata is missing, placed incorrectly, or inconsistent with its schema.

A url-safe base64 v2 envelope can be rejected before it is decoded. Missing EIP-712 extra fields can make the client and facilitator sign different domains. A free response can give an unpaid discovery probe a 200 when it expects a 402. These are response-level blockers 10x402 can surface; it does not inspect Bazaar’s index or infer demand.

Choose a lint, then pay and retry

Every paid route answers 402 first. The v1 terms are in the JSON body and the v2 terms are standard base64 in the PAYMENT-REQUIRED header. An x402-capable client holding USDC on Base reads those terms, pays, and retries the same request. There is no login or API key; the payment is the authorization.

POST /lint — $0.25 per report

Sends ONE unauthenticated request to the URL you name and lints the response: HTTP status, the v1 body envelope, the v2 PAYMENT-REQUIRED header envelope, dual-stack consistency, and CDP Bazaar discovery requirements. Returns a grade and a specific fix for each finding. It identifies technical blockers; it does not verify a listing or payment.

First, request the quote. This unpaid call returns HTTP 402 with the price and payment terms. It does not return the report yet.

curl -sS -X POST https://10x402.com/lint \
  -H 'content-type: application/json' \
  -d '{"url":"https://toolshed.lemon-agent.dev/convert/md-html","method":"POST"}'

Then let an x402-capable client pay and retry the same request. A successful paid retry returns the report.

{
  "grade": "A",
  "summary": {
    "versions_detected": [
      1,
      2
    ],
    "payTo": "0x0adc7adac7bbaffffbd73505711e42378c4f9f9e",
    "network": "eip155:8453",
    "price": "$0.001 (1000 atomic)",
    "bazaar_ready": true,
    "blockers": []
  },
  "findings": [],
  "checks_run": 76
}

POST /lint/one — $0.02 per report

The same outbound probe as /lint, reported for exactly one check you name. For settling a single question — "is my v2 header base64url", "does my bazaar info validate against its own schema" — without buying the whole catalogue. The answer says whether the check PASSED, and when the check did not apply to this response it says that instead of quietly passing. GET /check lists every check id, and publishes the batch arithmetic — so you can work out where the full report becomes the cheaper buy before paying for any of it.

First, request the quote. This unpaid call returns HTTP 402 with the price and payment terms. It does not return the report yet.

curl -sS -X POST https://10x402.com/lint/one \
  -H 'content-type: application/json' \
  -d '{"url":"https://toolshed.lemon-agent.dev/convert/md-html","method":"POST","check":"V2_B64_URLSAFE"}'

Then let an x402-capable client pay and retry the same request. A successful paid retry returns the report.

{
  "check": "V2_B64_URLSAFE",
  "applied": true,
  "passed": true,
  "finding": null,
  "regime": "payment",
  "severity": "error",
  "core": true,
  "sources": [
    {
      "kind": "client-code",
      "ref": "@x402/core@2.23.0 dist/cjs/utils/index.js:133 — Base64EncodedRegex = /^[A-Za-z0-9+/]*={0,2}$/"
    },
    {
      "kind": "client-code",
      "ref": "@x402/core@2.23.0 dist/cjs/http/index.js:1778-1781 — the regex is tested on the RAW header, then it throws, before any decode"
    },
    {
      "kind": "spec",
      "ref": "specs/transports-v2/http.md:7-25 § Payment Required Signaling — \"Base64-encoded\", SILENT on the alphabet",
      "context": true
    }
  ],
  "summary": {
    "versions_detected": [
      1,
      2
    ],
    "payTo": "0x0adc7adac7bbaffffbd73505711e42378c4f9f9e",
    "network": "eip155:8453",
    "price": "$0.001 (1000 atomic)"
  },
  "checks_run": 1
}

POST /lint/envelope — $0.10 per report

Runs the same check catalogue against a response you already have: paste the status, headers and body. Nothing is fetched, so it works for v1/v2 migration work, on staging, on localhost and on an endpoint that is not deployed yet. Cheaper than /lint for that reason: there is no outbound request to make on your behalf.

First, request the quote. This unpaid call returns HTTP 402 with the price and payment terms. It does not return the report yet.

curl -sS -X POST https://10x402.com/lint/envelope \
  -H 'content-type: application/json' \
  -d '{"status":402,"headers":{"content-type":"application/json"},"body":"{\"x402Version\":1,\"accepts\":[{\"scheme\":\"exact\",\"network\":\"base\",\"maxAmountRequired\":\"1000\",\"resource\":\"https://example.com/api/thing\",\"description\":\"an example paid endpoint\",\"mimeType\":\"application/json\",\"payTo\":\"0x0000000000000000000000000000000000000001\",\"maxTimeoutSeconds\":60,\"asset\":\"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\",\"extra\":{\"name\":\"USD Coin\",\"version\":\"2\"},\"outputSchema\":{\"input\":{\"type\":\"http\",\"method\":\"POST\",\"discoverable\":true,\"bodyType\":\"text\",\"description\":\"the request body\"},\"output\":{\"type\":\"string\",\"description\":\"the response body\"}}}]}"}'

Then let an x402-capable client pay and retry the same request. A successful paid retry returns the report.

{
  "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
}

POST /lint/envelope/one — $0.01 per report

One named check over a response you already have — the cheapest answer this service sells, and the one to reach for in a test or a CI step that asserts a single property of a 402 it just built. Nothing is fetched. The answer says whether the check PASSED, and when the check did not apply to this response it says that instead of quietly passing. GET /check lists every check id.

First, request the quote. This unpaid call returns HTTP 402 with the price and payment terms. It does not return the report yet.

curl -sS -X POST https://10x402.com/lint/envelope/one \
  -H 'content-type: application/json' \
  -d '{"status":402,"headers":{"content-type":"application/json"},"body":"{\"x402Version\":1,\"accepts\":[{\"scheme\":\"exact\",\"network\":\"base\",\"maxAmountRequired\":\"1000\",\"resource\":\"https://example.com/api/thing\",\"description\":\"an example paid endpoint\",\"mimeType\":\"application/json\",\"payTo\":\"0x0000000000000000000000000000000000000001\",\"maxTimeoutSeconds\":60,\"asset\":\"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\",\"extra\":{\"name\":\"USD Coin\",\"version\":\"2\"},\"outputSchema\":{\"input\":{\"type\":\"http\",\"method\":\"POST\",\"discoverable\":true,\"bodyType\":\"text\",\"description\":\"the request body\"},\"output\":{\"type\":\"string\",\"description\":\"the response body\"}}}]}","check":"V2_HEADER_PRESENT"}'

Then let an x402-capable client pay and retry the same request. A successful paid retry returns the report.

{
  "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
}

Read the report: fix payment blockers first

• A
• B
• C
• D
• F

Core checks are the failures that make an envelope unusable as published. One core error is an F. Ordinary errors are a D; warnings count toward B or C.

Severities: error — a client, a facilitator or the discovery index will reject or mis-read this; warn — it works, but it costs you something you probably want; info — a nit; never affects the grade.

Two verdicts, because there are two questions

The grade answers “can I be paid”, and only that. It counts payment-regime findings: the specs’ MUSTs, and what a shipping client parses, throws on, or refuses to sign.

summary.bazaar_ready answers “can I be found” — true, false, or "n/a" for a v1-only endpoint — from bazaar-regime errors, with the blocking codes listed in summary.blockers.

They come apart more often than you would expect, and the case that matters is grade A with bazaar_ready: false: an endpoint taking payments correctly that CDP will not catalogue. That is the exact shape sellers describe as “my endpoint passes validate but is not indexed”, and reporting it as a D told them their working endpoint was broken while burying the thing that was actually wrong.

checks_run is the number of catalogue checks that applied, not the total available. A v1-only response legitimately skips v2 checks.

Two things you should not have to take on faith

The suite also keeps a frozen 402 captured from a live production seller as a positive control. It is not presented as a current live-domain check.

The x402 conformance checklist: 79 published checks

77 checks inspect HTTP and x402 conformance. 2 report safeguards disclose truncated input or findings, so a partial report cannot read as clean. Every finding includes a code, message, severity, and specific fix.

Each check also names its regime and its sources. 49 checks are payment — the specs’ MUSTs and what shipping clients parse or throw on, and the only findings that set the grade. 24 are bazaar — what CDP requires to index you, reported as bazaar_ready instead. 6 are hygiene, which are info and never grade. A rule with no citation is an assertion, so every row carries one — including the ones whose honest answer is house-opinion.

• HTTP layer 6
• x402 v2 envelope (the PAYMENT-REQUIRED header) 43
• x402 v1 envelope (the 402 body) 21
• Dual-stack consistency 5
• Version-detection hygiene 2
• The report’s own bounds 2

x402 discovery and migration FAQ

Limits, stated plainly

• POST /lint sends one unauthenticated request with no payment header and follows no redirects. A redirect is reported as a finding.
• It reads at most 256 KB, and one 10s deadline covers the connection, headers, and body read.
• It refuses plain http, private and reserved addresses, private-network names, and ports other than 443 and 8443. Use /lint/envelope for anything else.
• At most 8 accepts[] entries are linted, at most 200 findings come back, and quoted input is clipped. Each bound reports itself.
• The URL guard does not pre-resolve DNS, so it cannot defend against DNS rebinding. This is a public-URL linter and should not be deployed where egress can reach a private network.
• It checks the published HTTP 402 and envelopes. It does not make a payment to the seller, confirm a live Bazaar listing, or measure demand.