What we learned signing our first ten providers
The good ones had documentation you could read without logging in. That correlation held better than anything else we measured.
We now have ten APIs in the catalogue, which is enough to notice patterns in how the conversations went.
The documentation tell
The single best predictor of whether a provider would be good to work with was whether we could read their documentation without creating an account. Not the quality of it — just whether it was public.
Providers who hid docs behind a signup wall were, without exception, slower to answer technical questions, vaguer about rate limits, and more likely to describe their uptime as "excellent" rather than as a number. Providers who published everything usually already knew their own p99 and were willing to have it printed next to their listing.
We started asking for the docs link first, before pricing.
The rate limit conversation
Almost nobody could tell us what happened at their rate limit without checking. Several assumed requests queued. In two cases they were dropped silently, which the provider learned during our evaluation.
We now require a documented, tested answer to one question before a listing goes live: what does a client see on the request that exceeds the limit? A 429 with a Retry-After header is the answer we want. Anything else needs a reason.
The thing we got wrong
We initially tried to normalise every provider's data model into a house schema. It worked for the first three, produced an unmaintainable translation layer by the sixth, and we abandoned it.
What we normalise now is the envelope — auth, errors, pagination, rate limits, dates. What is inside the data field belongs to the provider. Learning that boundary cost us about a month.
Ten providers is not a marketplace. It is enough to know the shape of the work.