SDKs — software development kits — are the language-native libraries that wrap an API’s operations so developers can use it in their preferred programming language without dealing directly with raw HTTP calls. Instead of constructing requests and parsing responses by hand, a developer imports the SDK and calls methods that feel native to their language. SDKs are a major part of the consuming side of APIs, the thing that turns an HTTP interface into something a developer can use idiomatically in Python, JavaScript, Java, or Go. I’ve written about SDKs and code libraries throughout my work, and my thinking has evolved considerably — from the early recognition that good SDKs matter for adoption, through the rise of automated SDK generation from definitions, to a more recent and more skeptical view of where SDKs actually fit in a world of machine-readable definitions and AI-assisted consumption. SDKs are valuable, but their role keeps shifting as the broader API toolchain evolves.
The early lesson was that providing code libraries matters but isn’t sufficient, and I wrote about it in 2011. Providing code libraries is not enough for your API, I argued — because a developer needs more than just an SDK; they need documentation, examples, and support around it. But the converse was also true: good SDKs genuinely reduce the friction of consuming an API, meeting developers in their language and letting them be productive faster. The early SDK landscape was largely hand-crafted — providers wrote and maintained libraries for each language they wanted to support, which was expensive and meant SDKs often lagged behind the API. Community-driven code libraries, which I wrote about in those early years, were one answer: letting the developer community build and maintain libraries for languages the provider couldn’t cover. The early SDK story was about the tension between the value of language-native libraries and the cost of building and maintaining them.
The generation breakthrough changed the economics of SDKs fundamentally, and I tracked it closely. Once you have a machine-readable API definition — Swagger, then OpenAPI — you can generate SDKs automatically rather than hand-writing them. I wrote extensively about this: generating client code from machine-readable definitions, the comparison of code-generation tools, and the rise of services like APIMATIC that specialized in SDK generation. This was a major shift: instead of hand-crafting and maintaining dozens of libraries, you could generate them all from a single definition, keeping them in sync with the API automatically. I did flag the honest caveat in 2015 that auto-generating code still means you’ll get your hands dirty — generated SDKs aren’t always as polished as hand-crafted ones, and the question of hand-crafted versus generated SDKs was a real tradeoff between quality and maintainability. But the generation capability transformed SDKs from an expensive manual burden into something that could be produced and maintained at scale from the API definition.
The specialization and maturation of the SDK space reflected the broader maturation of API operations. I wrote in 2016 about API SDKs getting more specialized, and about evolving the SDK with DX kits — the recognition that SDKs were becoming more sophisticated, more tailored to developer experience, more than just thin wrappers. The SDK became a lifecycle basic, a standard part of what a complete API operation provides. Azure’s SDK governance guidelines, which I wrote about in 2019, showed major providers treating SDK quality and consistency as a governed concern. The modern SDK-generation tools — APIMATIC, OpenAPI Generator, Kiota, Speakeasy — represent the maturation of this into a real category, generating high-quality, idiomatic SDKs from definitions. But I’ve also been honest about the pitfalls: SDK generation has real failure modes, as I wrote in 2025 about SDK generation pitfalls, where naively generated SDKs can be awkward, unidiomatic, or incomplete. Good SDK generation is harder than it looks, and the quality of the generated SDK depends heavily on the quality of the underlying definition.
The skeptical reframe I’ve developed is the most interesting part of my recent thinking, and it questions where SDKs actually fit. I asked directly in 2025 whether we should invest in SDKs or just an OpenAPI and API documentation — because in a world where consumers have the machine-readable definition, modern HTTP clients, and increasingly AI assistants that can work directly from the definition, the case for maintaining hand-tuned SDKs is less obvious than it once was. My provocative 2024 framing was that nobody cares about APIs or SDKs — meaning that what people actually care about is solving their problem, and the SDK is just one possible means to that end, not an end in itself. And in 2025 I argued there is only API consumption — the SDK being just one of several ways consumers might consume an API, alongside HTTP clients, collections, and direct definition-driven access. The question isn’t whether SDKs are good, but whether they’re the right investment given everything else available for consumption now.
Where I’ve landed is that SDKs remain valuable but their role is contingent and shifting, and the decision to invest in them should be deliberate rather than automatic. SDKs genuinely help developers who are building committed production integrations in a specific language — for that use case, a good, idiomatic SDK reduces real friction. But the assumption that every API needs a full suite of hand-maintained SDKs is increasingly questionable, because the machine-readable definition, modern HTTP clients, generated SDKs on demand, and AI-assisted consumption all provide alternative paths from the API to a working integration. The strategic question, as I framed it in 2025, is whether to invest in SDKs or to invest in an excellent OpenAPI definition and documentation that everything else — including on-demand SDK generation and AI consumption — can derive from. My lean is increasingly toward the definition as the foundation: get the OpenAPI and JSON Schema right, and SDKs become a generated derivative you can produce when and where they add value, rather than a primary artifact you hand-craft and maintain for its own sake. SDKs are one valuable expression of an API on the consuming side, but in the modern toolchain they’re a derivative of the definition, not the foundation — and recognizing that shifts the investment toward the machine-readable contract that SDKs, clients, documentation, and AI all ultimately depend on. The SDK still matters, but it matters as one of several ways to consume an API, generated from the definition that is the real source of value, rather than as the irreplaceable hand-crafted artifact it once was.
References
- Providing Code Libraries Is Not Enough For Your API
- Evolving How We Approach The API Lifecycle With APIMATIC
- Hand Crafted Or Generated SDKs For Your API?
- API SDKs Getting More Specialized
- API Life Cycle Basics: SDKs
- Azure Provides SDK Governance Guidelines
- Nobody Cares About APIs Or SDKs
- Do We Invest In SDKs Or Just An OpenAPI And API Documentation
- SDK Generation Pitfalls
