How to get your x402 API found by AI agents: discovery directories, Bazaar and gateways

Updated 2026-11-01

An x402 API is only useful if an agent can find it. Most agents do not know your URL. They search a directory, read a catalogue, or query a router. This guide lists the discovery paths we actually checked, what each one asks from the provider, and the order we would follow.

We wrote it from the public pages of each directory, read on 2026-11-01. Anything that changes after that date should be checked on the source page.

1. Make the endpoint payable first

Every directory below indexes endpoints that answer an unpaid request with HTTP 402 Payment Required and accept an x402 payment proof (USDC on Base in most cases). If your route is not payable, no listing will help.

The x402.new directory describes the usual setup: add x402 middleware in front of the routes you want to charge for. The middleware answers unpaid calls with a 402 and verifies the payment header on paid ones. Your handler code does not change. Middleware packages exist for Express, Hono, Next.js, FastAPI, Flask and Gin, according to the same page.

2. The Bazaar (Coinbase discovery layer)

The x402 Bazaar is the discovery layer that many directories read from. According to the x402.new page, services that use the Coinbase facilitator are discoverable automatically once they set discoverable: true in their payment config. You can also register explicitly through the Bazaar docs.

What to check:

• discoverable: true is set on each paid route.
• Each route has a one-sentence description that says what the endpoint returns, not only what it is.
• Input and output schemas are declared, with at least one example. Bazaar metadata powers the code samples on directory pages.
• A service name is set, so your routes are grouped under one provider.

3. x402.new: no form, automatic indexing

x402.new says it indexes the public x402 discovery network continuously. There is no submit form for providers. Once the Bazaar metadata is correct, the listing usually appears within the hour, and fixes to the description, price or schemas are re-synced without any action.

The directory sorts by price and shows 30-day usage, so a clear description and a fair per-call price matter more than a form.

4. x402scan: register your resources

x402scan lists resources and shows their usage. It has an explicit registration page for adding an API. Check the current instructions on the register page before you submit, because the flow has changed more than once in recent months.

5. Gateways that compare providers

Some gateways group several providers under one job, so an agent gets a ranked list and one payment rail. Apiosk is one example. Its public documentation describes a reverse proxy at gateway.apiosk.com/{api_slug}/{path}, plus discovery and comparison endpoints (/v1/discover, /v1/compare, /v1/decide). Its llms.txt is long, and we could not read the full provider onboarding section in one pass, so we do not give a procedure here. Read the full file at the source before you submit.

Gateways are worth the effort when they already send paying calls, because your listing competes on price, measured latency and success rate, and an unmeasured service can be filtered out. Check their published rules on how they measure those numbers.

6. Lists and registries

Public registries such as the MCP registry or awesome-lists are a different channel. They accept a server or a link, not a payable route. Read each list's contribution rules first. Some only accept servers the maintainer can run themselves, and remote-only servers are excluded from those.

A practical order

1. Check that every paid route is payable and returns a clear 402 body.
2. Set discoverable: true and write the Bazaar metadata: description, schemas, one example.
3. Wait for x402.new and the Bazaar to index the routes, then check them.
4. Register on x402scan if it is not already there.
5. Only then look at gateways, and read their onboarding page in full.

How an agent can check a provider before paying

Once you are listed, an agent should be able to read a short, honest description and a price, and then decide. Keep the description factual. Say what the call returns, what it does not cover, and the price per call. Agents and their builders filter out listings that promise more than the endpoint does.

If you sell a verification or a data lookup, the same rule applies: state the sources and the limits. For example, Tolca's business verification checks published sanctions and business registries and returns ok, review, blocking or not_found. It does not cover data about individuals. Being exact about scope is what makes a listing trusted.

Tolca's pages: https://tolca.tonbot.ca/guides and the machine-readable catalogue at https://tolca.tonbot.ca/openapi.json.