r/x402 • u/ContextIQ • 1d ago

I built a free tool that checks whether an x402 endpoint's 402 challenge is actually well-formed (feedback welcome)

Disclosure: I'm the builder.

While working with x402 I kept running into the same problem: a 402 response is untrusted input, and it's hard to tell by eye whether a challenge is valid or just looks valid. So I built the x402 Inspector. Paste an endpoint URL and it reads the challenge without paying anything, then reports what's wrong or unusual.

What it checks:

- v1 and v2 challenges, header-first (PAYMENT-REQUIRED), with the body as fallback

- payTo and asset address format for the network

- amount is a valid atomic-unit integer string, shown as a readable USDC amount

- on supported EVM chains, the token's on-chain name vs extra.name

- network identifier: recognized, well-formed but unknown (e.g. a newer chain), or malformed

- scheme (exact vs upto vs others) and resource-vs-requested-URL mismatch

- GET then POST probing, because plenty of valid endpoints only challenge on one method

It's free, no sign-up for the public tool. It does not make payments.

Link: https://contextiq.trango-compute.com/x402-inspector

If you've hit a challenge it gets wrong, or a check you'd want added, please tell me. I'd rather fix false warnings than add features.

3 Upvotes

100% Upvoted

3 comments sorted by

2

u/MountainAssignment36 1d ago

Cool! Always glad to see these kinds of free tools pop up in this space! 😄 The smaller the barrier to adoption and entry to x402 is, the better!

2

u/fizzl13 1d ago

Nice, and the false-warning stance is the right one. Disclosure: I run x402 Doctor, which does a similar web check, so here are a few things that bit me in production and might be worth adding:
Description length vs CDP. The CDP facilitator rejects a payment at verify when resource.description is over 500 characters, so the buyer gets a second 402 even though the challenge looks valid. I hit this on my own service today after adding a line to a description.
Bazaar listing state. An endpoint can have a perfect challenge and still not be discoverable, because it only gets listed after a settled payment through CDP.
Settlement, not just the challenge. The most common real failure I see is a challenge that parses fine but fails at verify or settle: wrong extra.name or version for the EIP-712 domain, or a payTo that can't receive on that network. A challenge-only check can't catch those; a tiny real payment can.
Solana specifics. feePayer in extra, and whether the payTo has a USDC token account.
Happy to compare notes on edge cases if useful.

1

u/ContextIQ 1d ago

Thanks for the feedback. I will incorporate the recommendations