x402 Bazaar Listing Monitor: catch a vanished listing before your revenue does

If you sell over x402, your buyers find you through Coinbase CDP’s Bazaar discovery catalog. It’s the directory that lets an agent or a buyer’s client discover your payTo address and the resources you serve. Settlements happening normally tells you the payment rail works. It tells you nothing about whether you’re still listed.

That gap matters because CDP’s discovery API has a recurring, publicly-reported class of bug where a resource silently stops appearing in the catalog — despite payments continuing to settle against it correctly. Nothing errors. Nothing notifies you. The first signal most sellers get is a revenue dip days later, and by the time you notice the dip, you’ve already lost however many buyers couldn’t find you in between.

How to check it yourself, right now

You don’t need our tool to find out whether this is happening to you today. CDP exposes the same discovery data it hands to buyer clients, and you can query it directly:

curl "https://api.cdp.coinbase.com/platform/v2/x402/discovery/merchant?payTo=<your-0x-address>"

Compare the resource URLs that come back against the list you actually serve. Anything missing that should be there is the failure mode above — or a config issue worth double-checking. If you want to be thorough, re-run this after every deploy and every so often between them, since nothing on CDP’s side will tell you if it happens again.

That’s the whole check. It’s simple enough to do by hand, and if you’d rather keep doing it by hand, you now know exactly what to run. You’ve lost nothing by reading this far.

What we automated

The check doesn’t change if you run it once or run it forever — only whether a human remembers to. So we built a scheduled version of it.

x402 Bazaar Listing Monitor registers your payTo address and the resource URLs you serve, then polls the same public discovery catalog on a 6-hour cron and diffs the result against what you registered. When a resource drops out — or comes back — the state change is recorded with a timestamp inside the service, instead of you having to notice and remember when things went wrong.

There’s also an on-demand path with no registration at all: an MCP tool, check_listing_health, that runs the identical diff for any payTo/resources pair, registered or not.

parameter	type	notes
payTo	string	0x-prefixed, 40 hex characters
resources	string[]	1–200 http(s) URLs

No signup, no API key — call it and get back each resource flagged as listed or missing. Find it on the official MCP registry or on Smithery.

What this is, plainly

This is a scheduling and alerting layer on top of the same public data CDP already exposes — not a replacement for CDP’s own troubleshooting guidance, and not a claim that we see something CDP doesn’t. The value is vigilance kept up on a schedule you don’t have to remember, not a unique data source.

Two things worth being exact about, because they’re easy to overstate:

• The free tier polls every 6 hours, not instantly — and that’s a real trade, not a rounding error. A drop that persists to the next poll is caught. A drop that fully recovers in between two polls produces no record at all: the check only ever compares one poll to the next, so anything that happens and un-happens inside a 6-hour window is invisible to it. Paid tiers tighten the interval; pricing for those is opening soon — register your interest if you want to hear when they land.
• Delivery and history retrieval aren’t exposed yet. A state change is detected and recorded with a timestamp inside the service the moment it happens — that part is real and already running. What isn’t built yet is a way for you to pull that record yourself, or have it pushed to you (email, webhook, whatever it ends up being). Until both of those exist, the manual check above is your actual read path: this tool decides when the check runs; it doesn’t yet show you what it found.

Neither of those is a small print. Deciding whether that’s the right trade for your setup is exactly what the manual check above lets you do first.

Try it

• Register for scheduled polling: x402-listing-monitor.acjlabs.com
• Call it with no signup: the check_listing_health MCP tool, via the official MCP registry or Smithery
• Questions or a bug report: contact@acjlabs.com or @acjlabs.com on Bluesky