How to list an x402 API and earn the settlement-verified badge

Listing an x402 API is the start of the process, not the proof that a paid call works. PayAPI Market separates endpoint submission and challenge response from settlement verification. For providers, that distinction matters: a listing can be present and responsive without yet carrying the settlement-verified badge.

Here is a practical path from a callable endpoint to a verified listing. The marketplace does not charge providers to list, and providers keep 100% of what each call earns. Buyers pay the listed per-call price in USDC on Base, Solana or Algorand where the listing offers that network.

1. Choose one endpoint that can stand on its own

Start with a single durable endpoint rather than trying to publish an entire service at once. Pick a request that returns a useful, clearly defined result. A postcode lookup, an email check or a currency rate is easier to describe and test than a broad API surface with many unrelated operations.

Before listing, call the endpoint yourself. Confirm that it returns the expected product for a normal request, that its response is usable, and that the service will remain available for agents making future calls. Write down the request shape, response format, price per call and any limits a buyer needs to know. Keep the description aligned with what the endpoint actually returns.

If you are still shaping a data service into a per-call product, this walkthrough of preparing a domain API for agent calls covers the product decisions that come before a listing.

2. Submit the API for listing

Use PayAPI Market’s API listing page to submit the endpoint. Listing is free. Provide the information the submission process requests, and make sure the endpoint and its description agree. A vague listing creates uncertainty for both the marketplace’s checks and the agent deciding whether to spend.

Be precise about the unit being sold. If one request returns one result, price and describe that request. If an endpoint performs a more complex task, explain what the buyer receives from that call. Do not imply that every network is available for the listing: payment is in USDC on Base, Solana or Algorand where that listing offers it.

Keep the endpoint reachable while the submission is being checked. A service that answers only from a developer’s local machine is not ready for agents or marketplace testing. Make sure your deployment can handle the requests your listing describes, and that its response does not depend on an undocumented manual step.

3. Respond to the listing challenge

A submitted listing must respond to a challenge. Treat this as an endpoint check, not as the paid verification itself. Follow the challenge’s stated request and response contract. Do not guess at a payload or return a generic success response if the challenge expects a particular result.

Test the same behavior against your deployed endpoint before relying on the marketplace check. Confirm that the request reaches the intended route and that the response is valid and complete. If you change the endpoint while resolving a challenge, test it again; a successful response from an old deployment does not establish that the current listing works.

PayAPI Market distinguishes a listing that has been submitted and responds to a challenge from a settlement-verified listing. The challenge response is useful evidence that the endpoint answers. It does not establish that a buyer’s crypto payment settles or that the paid call returns the product.

4. Let the marketplace test a real payment

The settlement-verified badge is added after PayAPI Market tests the endpoint with a real crypto payment. The marketplace describes the check as paying from its own buyer wallet and confirming that the product comes back. In other words, the test covers both sides of the transaction: settlement and delivery.

That is why a successful unpaid check is not equivalent to a badge. A listing marked as submitted or challenge-responsive has not necessarily passed a paid call. PayAPI Market says the badge is backed by a matching settlement record and cannot be set without one. Providers should not describe a challenge response or an unpaid check as settlement verification.

If the paid test does not complete, review the endpoint’s payment handling and response behavior, then correct the underlying issue. Avoid changing the listing description to claim a result the endpoint has not delivered. The verification is about the tested call, not a general promise about every possible request.

5. Keep the listing honest after verification

Once the badge appears, keep the endpoint and its stated price consistent with what was tested. Monitor availability and response quality. If the route changes or the service stops returning the described data, fix it promptly. A badge is a record of a successful settlement test, not a substitute for operating the API reliably over time.

For providers, the economics are straightforward: listing costs nothing, PayAPI Market takes no per-request fee, and the provider keeps 100% of call revenue. The practical work is in making a small, clearly described endpoint dependable enough to answer an agent’s request, accept the payment path offered for that listing, and return the promised result.