By Chet Parker · Published 2026-09-02 · Last updated September 2, 2026 · 4 min read

An agent that can pay does not need an account, a key or a contract. What it does need is a way to decide which of the listings in front of it is worth spending on. That decision now has something to read.

The four calls have not changed

Discovery is still free and still four commands, all of them runnable right now:

curl -sS "https://payapi.market/agent/search?q=property"
curl -sS "https://payapi.market/agent/get?id=uk-hmo-licence-api"
curl -sS https://payapi.market/openapi.json
curl -sS -i "https://hmo.payapi.market/v1/licences?postcode=M1+1AE"

Search, read one listing, take the whole machine-readable contract, then call the provider and answer its own 402 from your wallet. PayAPI Market is not in the payment path at any point. The full walkthrough lives at how an agent finds PayAPI.

What is new: a reliability object on every listing

Every result from /agent/search, /agent/list and /agent/get, and every result from the MCP tools, now carries this:

"reliability": {
  "score": 82.4,
  "band": "strong",
  "computed_at": "2026-09-01T04:00:00.000Z"
}

Three fields. The score runs 0 to 100 or is null. The band is one of strong, established, thin, caution or unscored, so an agent can branch on a word instead of picking its own thresholds. computed_at tells you how stale the number is, which matters more than the number itself on a listing nobody has touched in a month.

Read the band, not the digits. strong is 80 and above, established is 50 to 79, thin is 26 to 49, caution is 25 and under, and unscored means we have not computed one yet. Unscored is not an accusation. It usually means the listing is new.

Where the number comes from

Not from reviews. Nobody rates these APIs and there is no upvote to buy. The score is computed from three things that either happened or did not:

• Verification. Did we pay for a route from our own wallet and get real product back, with the settlement on-chain? Recent payments count for more than old ones.
• Health. How has the endpoint answered its health checks since? Samples where our own monitoring was blocked are excluded rather than counted as failures, because a blocked check is not a broken API.
• Integrity. Does the wallet in the live payment challenge still match the wallet on record? If it has been swapped, this part goes to zero.

There are named modifiers on top, and a listing under an active hold is capped no matter how good the rest looks. The intent is a score that is slow to earn and quick to lose.

What it is not

It is not a security audit. It is not a promise the API will be up when you call it. It is not a claim about output quality beyond the one route we paid for: a listing with many routes and a high score still only tells you about the route we tested. And it is not a substitute for reading the 402 challenge, which states the exact price before any money moves.

Treat it as one input. An agent with a budget and a deadline can reasonably prefer strong over thin, fall back when the first choice fails, and refuse caution outright. That is a better policy than trusting a badge, and a much better one than trusting a description.

What did not change

No fee. Listing is free and providers keep 100% of what the call earns. The verified badge still means exactly what it always meant: we paid for one route on that listing and got product back. Reliability sits beside that badge; it does not replace it, and it never sets it.

The fields the score is built from stay private. Publishing the component breakdown would name other listings' failure modes and hand anyone who wanted to game the formula a map. The method is public, on the guide page. The inputs are ours.