Comparing x402 API marketplaces is now a real task rather than a hypothetical one. There are protocol-level discovery indexes, curated marketplaces, community crawls and comparison layers, and all of them list paid endpoints that agents can call. They look similar from the outside and answer very different questions, so the useful way to compare them is by what each one can actually prove.
A directory, an index and a comparison layer are different products
A directory lists services that submitted themselves or were imported. An index crawls and stores what it finds, often at large scale. A comparison layer takes candidates that can do the same job and measures them against each other under one method.
All three are useful. A large index is the right place to be found by an agent that has never heard of you. A comparison layer is the right place to be chosen against alternatives. The mistake is to treat a listing in the first as if it were evidence from the third. A provider that appears in an index has been seen. That is not the same as having been called, measured or reviewed.
Five questions that separate them
Most of the difference comes down to five questions. They apply whether you are a provider deciding where to list or a buyer deciding whose ranking to trust.
- What is measured: price only, or also latency, success rate and input compatibility.
- Where it is measured from: the seller's own report, a periodic probe, or calls routed by real buyers.
- Whether the ranking can be recomputed: are the weights and each candidate's inputs published with the score.
- Whether it shows what it left out: rejected candidates with the reason, and dimensions it has not measured.
- Where the trust boundary sits: which listings are reviewed and settleable, and which are only indexed.
A marketplace that answers all five clearly is doing comparison. One that answers only the first is a catalogue with a sort order.
What is measured, and from where
Rankings differ most in their source data. Some order services by transaction volume. Volume is easy to count and hard to interpret: it rewards whoever already has traffic, it can be inflated by a seller paying itself, and it says nothing about whether the calls succeeded or what they cost.
Others probe endpoints on a schedule and report uptime and latency. A probe measures whether the endpoint answers a synthetic request from one location. It does not see the timeouts, malformed bodies or payment failures that real buyers hit, which is why it matters to know what counts as a successful API call in any reliability figure you are shown.
The third source is measurement from calls that buyers actually routed through the layer. That is the closest to what a buyer will experience, but it only exists for endpoints with enough traffic, and an honest layer says so rather than filling the gap.
Seller-reported figures are the weakest source of all, for a structural reason covered in why API providers cannot compare themselves: the party being ranked is not a neutral witness to its own position.
Can the ranking be recomputed
A score you cannot recompute is an opinion with a number attached. Before trusting a marketplace ranking, check whether every score arrives with the weights that produced it and each candidate's contribution per dimension. If it does, a buyer can change the weights to match its own workload and see whether the order holds.
This is the standard argued for in recomputable API scores. It also exposes a subtle point: in a fair comparison, scores are relative to the candidates in that one set. A provider's score is not a grade it carries everywhere. It describes its position among those particular alternatives, and it moves when the set changes.
Does it show what it left out
Two omissions separate a comparison from a leaderboard.
The first is rejections. A useful decision names every candidate that was removed and the exact constraint that removed it. A leaderboard shows only the winners, so a provider cannot tell whether it lost on price, on latency or because it was never considered.
The second is unmeasured dimensions. When a marketplace has no latency data for a candidate, it can score it as zero, quietly drop it, or drop the dimension and name the omission. Only the last one is honest. Scoring missing data as zero punishes new providers for being new, and silently dropping it makes a partial comparison look complete.
Where the trust boundary sits
Every marketplace that combines several sources has to decide which listings it vouches for. The clearest ones draw a visible line between reviewed listings that can be compared and settled, and indexed listings that have only been found. The reasons that line matters are set out in the piece on reviewed versus unreviewed API listings.
Watch for the same endpoint appearing more than once. Combining sources without matching them produces several copies of one provider, and deduplicating API listings across directories is the step that stops a provider from being ranked against itself.
Where Apiosk fits
Apiosk is a comparison layer, not an index. `GET /v1/compare?candidates={id},{id}` returns price, measured latency, measured success rate and input compatibility side by side, each scored 0–100 relative to the candidates in that comparison. Every response carries the weights and each candidate's contribution per dimension, so the score can be recomputed. Latency and success rate are measured only for listings Apiosk has proxied enough calls of. Where a dimension has not been measured, it is dropped from the weighting and named, never scored as zero. Apiosk does not measure result quality or provider terms.
`GET /v1/decide` returns one provider, the rule that picked it, every rejected candidate with the constraint that removed it, and the runners-up in order. Discovery also sweeps external x402 sources, but those hits come back in a separate `external_candidates` block without a `candidate_id`, unreviewed and unmeasured, and they cannot enter comparison or decision.
If you sell a paid endpoint, keep listing it in the indexes that bring reach, and list it as a reviewed provider on Apiosk where it can be compared on evidence.
Frequently asked questions
Is the x402 marketplace with the most listings the best one to use?
Not necessarily. A large index is useful for reach, but listing count says nothing about whether any listing has been called, measured or reviewed. For choosing between providers, what matters is how the marketplace measures candidates and whether you can check its ranking.
What is wrong with ranking x402 services by transaction volume?
Volume rewards whoever already has traffic and can be inflated by a seller paying itself. It also says nothing about price, latency or whether the calls succeeded. It is a popularity signal, not a comparison.
Should a provider list on more than one x402 marketplace?
Usually yes, because each one reaches different buyers. Publish one canonical discovery document on your own domain and point every marketplace at it, so the listings stay consistent and can be matched to each other rather than counted as separate providers.
How can a buyer check that a marketplace ranking is fair?
Ask for the weights and the per-dimension inputs behind each score, then recompute it. If the marketplace cannot show what it measured, from where, and which candidates it removed and why, the ranking cannot be verified and should be treated as editorial.