664 providers and 650 APIs on the network carry the SDK tag — companies that ship client libraries alongside their contracts rather than leaving you to generate your own.
Against 26,530 providers in the catalog, that is roughly 2.5%. The overwhelming majority of API providers hand you a specification and wish you luck.
The tag and the area disagree, usefully
The network carries two views of this. The SDK tag captures 664 providers who signal that they ship client libraries. The SDKs area captures 348 providers working in SDK tooling — the generators, not the generated.
Different questions. “Do you ship an SDK” is a developer-experience commitment. “Do you sell SDK generation” is a business. Swagger Codegen, Speakeasy and General Translation live in the second; the 664 live in the first.
What shipping an SDK actually signals
It is one of the more honest proxies in the catalog, because an SDK is expensive in a way documentation is not.
A client library has to be versioned against the API. It has to be published to a package registry. It has to be updated when the contract changes, in every language you claim to support, and every one of those updates is a release with a changelog and a deprecation path. A provider that ships SDKs across five languages has committed to five ongoing maintenance streams that only exist to make someone else’s integration easier.
Nobody does that accidentally. It is a durable signal of intent in a way that a well-written getting-started page is not.
The generated-SDK question
The economics changed. Generating a usable client from an OpenAPI specification is now good enough that a provider with a clean contract can ship five languages from CI without a dedicated team.
Which quietly raises the bar rather than lowering it. When SDK generation was hard, shipping libraries proved investment. Now that it is cheap, not shipping them mostly proves the contract is not clean enough to generate from. A specification good enough to produce a working client is a specification good enough to describe the API — and the reverse is the tell.
The 2.5% figure should be read in that light. It is not that 97.5% of providers decided SDKs were unnecessary. For most, the contract will not support it.
The agent angle
There is a reasonable argument that SDKs matter less now, because an agent reading an OpenAPI specification does not need a Python client — it needs the contract, the auth model, the error semantics and the rate limits.
That argument holds for the calling. It does not hold for what the SDK forces you to do upstream: pin a version, model the errors as types, name the operations coherently, and keep all of it in sync with the contract. The discipline that produces a good SDK is the same discipline that produces a contract an agent can use.
Takeaway
664 providers ship client libraries — about 2.5% of the catalog. Cheap generation has turned the SDK from proof of investment into proof of contract quality: if you cannot generate a working client from your own specification, that is the finding.
Browse the tag at apis.io/tags/sdk/, and the tooling area at sdk.apievangelist.com.