How Watch402 works

Watch402 continuously monitors every paid-API listing published in the two x402 discovery catalogs — the PayAI Network Bazaar (facilitator.payai.network/discovery/resources) and Coinbase CDP x402 Discovery (api.cdp.coinbase.com/platform/v2/x402/discovery/resources). As of August 2026 that is roughly 41,000 unique endpoints after de-duplication between the two catalogs.

The probe

x402 is a payment protocol built on the HTTP 402 Payment Required status code. When a client fetches a paid endpoint without paying, the server returns 402 with a PAYMENT-REQUIRED header containing base64-encoded JSON: the resource, an accepts[] array of payment options (scheme, network, amount in atomic units, asset contract, payout wallet), and optional discovery extensions.

That response is exactly what a paying client sees first — so we reproduce it. For each listing we request the exact resource URL using the HTTP method and example inputs the catalog declares (path parameters, query strings, POST bodies), sending browser-like headers plus an X-Watch402-Monitor contact header so operators can identify or allowlist us. We parse the returned challenge and compare every field against what the catalog advertises. We never send USDC and we never hold funds. The protocol hands us everything needed to audit a listing for free.

What a check covers

• Reachability — does the endpoint respond at all, and how fast?
• Spec conformance — does the 402 carry a parseable PAYMENT-REQUIRED header (x402 v2, with a v1 fallback)?
• Price drift — does the live amount match the advertised price?
• Wallet drift — does payTo still match the registered payout wallet?
• Network drift — is the advertised chain still what the endpoint demands?
• Scheme & method drift — does the accepted scheme and HTTP method still match?

The verdicts

• live — serves a valid 402 matching its listing.
• mismatch — serves a valid 402 that differs from the listing (price, wallet, network or scheme).
• invalid_402 / unexpected_200 — broken payment setup: unparseable or missing challenge, or no challenge at all.
• broken — HTTP error responses (404, 410, other 4xx, 5xx).
• timeout / fetch_error — unreachable.
• unknown — templated URL without enough example input to probe; never counted as broken.
• unprobed — queued, not yet checked.

Checking policy

Checks are scheduled by health. Anything serving payments (live, drifted, misconfigured) is rechecked at least every 24 hours; dead or unreachable endpoints are swept on a 7-day cycle. Newly ingested and newly claimed listings jump the queue. Capacity comes from five cron triggers running probe sweeps throughout each UTC day.

*/15 * * * *   probe sweep
0 * * * *      hourly bonus sweep
0 */6 * * *    long-tail sweep
0 0 * * sun    weekly catalog refresh from both bazaars
0 3 * * *      Telegram alert delivery

Claims, payments and alerts

Every listing gets a public status page at /s/{id}. An owner can claim it free by signing a message with the listing's own payTo wallet — proof of ownership without accounts or email. Alert delivery over Telegram costs $5 USDC on Base for 30 days, payable two ways: a plain USDC transfer whose transaction hash we verify on-chain, or natively through x402 by retrying POST /v1/x402/alerts with a PAYMENT-SIGNATURE header (EIP-3009, settled through the PayAI facilitator). Alerts fire when a listing goes down, recovers, or drifts from its advertised terms.

Try it

Paste any x402 endpoint into the checker on the homepage and see exactly what a paying client sees. Every monitored listing has its own public status page with its current verdict, price, wallet, network and last check time.

Own a listing? Claim it free from its status page to arm Telegram alerts — that's the only "signup" Watch402 has.