x402 Inspector via Wire v2: A Technical Tutorial for Scanning Payment Challenges

x402 Inspector checks whether a URL returns a spec-compliant x402 payment challenge — the kind of check you want before wiring an agent up to pay something it's never talked to before. This walkthrough covers its wire v2 endpoint specifically: what's different from v1, the exact request/response shapes, and two ways to call it, one with an API key and one by actually paying for it with x402.

Why v2 Is a Different Case, Not Just "the Newer One"

x402 v1 puts the payment challenge in the JSON response body. In v2, that challenge moves into a base64-encoded PAYMENT-REQUIRED response header instead — the spec calls the body itself "a server implementation concern," meaning a server is free to leave it empty, put a human-readable message there, or duplicate the header's contents. Network identifiers also change format, from a bare string like base to a CAIP-2 identifier like eip155:8453. And the client's signed payment proof arrives via a PAYMENT-SIGNATURE header instead of v1's X-PAYMENT.

That header-vs-body distinction isn't academic. We ran x402 Inspector against 50 live x402 endpoints pulled from Coinbase's public Bazaar discovery catalog, and every valid challenge we found was wire v2 — v1 has essentially disappeared from what's actively listed. Of those v2 challenges, 57% had a response body that disagreed with their own authoritative PAYMENT-REQUIRED header — different accepts[], different network, sometimes an empty body entirely. A client that naively parses the body instead of the header will compute the wrong price or the wrong network. x402 Inspector reads the header first and flags the mismatch as a warning when it finds one, specifically because this turned out to be common, not rare.

The Endpoint

POST /api/v1/x402-inspector/x402-v2
Price: $0.02 per call
Body: { "url": "<endpoint to scan>" }

This is the wire-v2 sibling of /api/v1/x402-inspector — same scanning logic underneath, different protocol for how you pay for the call itself. It's worth being precise about that distinction: the wire version you use to pay ContextIQ is unrelated to the wire version of whatever endpoint you're asking it to scan. You can call the v1 route to check a v2 target, or the v2 route to check a v1 target — the scanner detects the target's version on its own.

Option A: API Key

The simplest path if you're calling this from a server you control:

curl -X POST https://contextiq.trango-compute.com/api/v1/x402-inspector/x402-v2 \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com/paid-endpoint"}'

Keys come from the Developers page, which is viewable without an account — only key creation itself requires signing in.

Option B: Pay Per Call With x402, No API Key

Call it with no payment attached first, and you get a structured 402 back — not an error, a machine-readable challenge:

curl -i -X POST https://contextiq.trango-compute.com/api/v1/x402-inspector/x402-v2 \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com/paid-endpoint"}'

HTTP/1.1 402 Payment Required
payment-required: eyJ4NDAyVmVyc2lvbiI6MiwiZXJyb3IiOiJQYXltZW50IHJlcXVpcmVkIiwi...

{"x402Version":2,"error":"Payment required","resource":{...}}

That's the pattern described above, live: the real challenge is the base64 blob in the payment-required header, decodable as JSON ({x402Version, error, resource, accepts, extensions}). Sign and retry with an x402 v2-aware client — x402-fetch (unscoped) only speaks v1, so this needs the scoped @x402/fetch package instead:

npm install @x402/fetch @x402/evm

import { createWalletClient, http } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { base } from "viem/chains";
import { wrapFetchWithPayment } from "@x402/fetch";

const account = privateKeyToAccount(process.env.WALLET_PRIVATE_KEY as `0x${string}`);
const client = createWalletClient({ account, transport: http(), chain: base });

const fetchWithPayment = wrapFetchWithPayment(fetch, client);

const res = await fetchWithPayment("https://contextiq.trango-compute.com/api/v1/x402-inspector/x402-v2", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ url: "https://example.com/paid-endpoint" }),
});

const result = await res.json();
console.log(result);

Under the hood: @x402/fetch decodes the payment-required header, signs a USDC payment on Base, and retries with the proof in a PAYMENT-SIGNATURE header. No account, no API key — just a small amount of USDC on Base.

Reading the Response

{
  "target": "https://example.com/paid-endpoint",
  "status": "valid",
  "evidence": ["Responded 402 with a well-formed x402 payment challenge"],
  "warnings": [],
  "details": {
    "methodUsed": "GET",
    "httpStatus": 402,
    "x402Version": 2,
    "accepts": [{ "scheme": "exact", "network": "base", "maxAmountRequired": "20000" }]
  }
}

status is one of valid, invalid, malformed, or no_challenge. Don't stop at status, though — check warnings even on a valid result. That field is where the body/header disagreement noted above shows up, along with a handful of other spec-hygiene checks: an unrecognized network identifier, a declared resource URL that doesn't match the URL you actually scanned, or a payment amount that isn't a valid non-negative integer string.

details also carries methodUsed — the actual HTTP method the scan settled on. If a target declares its required method via a Bazaar discovery extension (extensions.bazaar.info.input.method) and that differs from the method the initial probe used, x402 Inspector retries with the declared method automatically before giving up, and evidence will note that it did.

Try It

Every request and response shape above is real — pulled from live scans, not illustrative. x402 Inspector is free to use from the dashboard for one-off checks by hand, or callable via either route above for wiring into a client that needs to validate a counterparty's payment challenge before trusting it.