Before Stainless was founded, engineering leaders at API companies often sought out Alex for the same piece of advice.

Alex had written the SDK generator used at Stripe, and so every company that wanted a Stripe-like API (with polish and adoption to match) asked the same question:

Should I have language-specific SDKs for my REST API?

Alex’s tongue-in-cheek response (before Stainless) was:

Yes, but you can’t have them.

Why did Alex respond this way? A great question, which we’ll answer in this blog post about why your API might need a language-specific SDK.

Why you should have an SDK

Based on his experience at Stripe, Alex was asserting that aspirationally every company should want SDKs for their REST API, as they confer a number of advantages.

Strongly-typed, language-specific interfaces reduce the time required to correctly implement an API. This drives:

Greater API adoption and overall usage

Competitive wins over solutions that are harder to use

Lower support burden for users of your API

Faster time to value for API users

For internal use cases, SDKs reduce the surface area of potential errors by providing consumers of internal APIs with compile-time hints and errors. This lets internal developers move faster and with more confidence. Enterprises will also often cite language-specific SDK support as a mark of maturity for an API.

Consumers of a REST API will ultimately build their own “SDK” on top of [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) or other HTTP libraries. If you don’t ship an SDK, you will end up supporting or re-implementing dozens (maybe thousands) of bespoke “SDKs” that aren’t type safe, and don’t do HTTP very well.

Code execution is emerging as one of the most reliable ways for AI agents to integrate against an API. Having a robust, idiomatic, and strongly typed SDK for a model to use is critical to realize these gains.

There’s a reason every major API vendor, from Stripe to Twilio to Anthropic, all provide robust SDK support across many programming languages. If you care about whether developers are successful using your API, you should should ship language-specific SDKs.

Why you “couldn’t have SDKs” historically

Alex’s sardonic “…but you can’t have them” qualification to the titular question of this post was based on the fact that historically, language-specific SDKs for a REST API had been prohibitively difficult to create and maintain. An incomplete list of challenges include:

Hand-maintaining REST API SDKs for every programming language requires multiple full-time engineers with expert-level knowledge of the underlying language.

Making good HTTP clients is not trivial - handling error states, retries, and robustly handling all the tiny corner cases of using an API over a network requires thoughtful implementation.

Even with all the engineers in the world, manually syncing up SDKs with a rapidly evolving REST API is difficult and error prone.

Open source SDK generators (using an OpenAPI spec) usually produce substandard results that developers won’t want to use.

To address these problems, Stripe invested years and millions of dollars to create custom technology that could reliably produce high-quality SDKs from a specification (as did Twilio during the same timeframe). But for the vast majority of companies, this approach was not economical or feasible.

The Stainless SDK generator was created using similar techniques as the Stripe generator to solve this problem - to make a critical developer interface much better for end users, and make exceptional DX and robustness attainable by any company.

So the people who sell an SDK generator think you should have SDKs? Surprise, surprise.

Fair point. While I stand by the logic outlined above, the effect of SDKs on API usage and adoption can be difficult to measure empirically, and most companies don’t share API usage data by User-Agent publicly. However, there are a few compelling public datapoints to consider.

API-first companies ship SDKs

Any company with a significant investment in APIs, from Google Cloud to Datadog, have an extensive offering of client SDKs in a variety or programming languages, both first-party and community-developed. These companies care whether or not developers successfully adopt their API, and invest accordingly.

Developers prefer language-specific SDKs

Developers very clearly vote with their feet, preferring to use client SDKs in their chosen programming language when possible.

The OpenAI TypeScript SDK (generated with Stainless) is downloaded over five million times every week (over 250M times a year), making it one of the most popular packages on npm among API vendors.

OpenAI doesn’t (yet) publish an official SDK for PHP, but a community-maintained library on Packagist has been downloaded over 18 million times, about a third of Laravel, a modern and popular web framework for PHP.

Code is how AI agents will use your API most effectively

There is growing evidence and logical basis for code execution being the most effective way for AI agents to integrate against your API. In this paradigm, a strongly-typed REST API SDK is required for models to reliably interface with your API. Strongly typed SDK code can be statically analyzed for correctness, so a model can correct lint errors and API shape problems when building an integration.

In a world where agents will do more and more work on behalf of people, every company must become an API company that can effectively serve AI agents as API consumers.

Do you need an SDK for a specific language?

If you’ve made it this far, you might be convinced that REST API SDKs are probably a good idea in general. But are they required across all languages? If you have SDKs for Python and TypeScript, do you really need one for PHP and Java as well?

Here’s how you might go about answering that question for your API.

Silent cost of not having an SDK

Your existing customers might not be banging down your door asking for an SDK in their preferred programming language. But let’s consider what may be happening instead, assuming that you have, say, Java developers that are using your API without a language-specific SDK:

Java developers are using incorrect hand-maintained API schemas that may break at runtime in the future

They are using the built-in HttpClient in a suboptimal way, leading to bugs and additional support burden

They are not adopting new features in your API, because you have no way to smoothly upgrade them to new API shapes

Your API users might be getting by without SDKs right now… but at what cost to them and you? And how many customers went with a competitive solution because they had a Java SDK and you didn’t?

Would even one key customer be unblocked?

If you are sold on the utility of SDKs in general, it might be easy to intuitively understand that SDKs for top programming languages like TypeScript and Python are essential. But what about languages with smaller communities, like PHP and Go, clocking in at numbers 15 and 16 respectively on the TIOBE index?

Size of a programming language community is the wrong question to be asking. The right one is “would I potentially unblock one or more customers who would make my incremental investment worth it?”

In every programming language community, it is very likely that an attractive customer can be found within it. Here are a few examples of logos you’d probably love to have on your website that use programming languages other than TypeScript and Python.

Programming Language	Notable Users
Ruby	GitHub, Stripe, Shopify, Airbnb, Coinbase
PHP	Meta, Slack, Etsy, Spotify
Java	JP Morgan Chase, Netflix, Google, Oracle
C#	Microsoft, Walmart, Starbucks, UPS
Go	Uber, Twitch, Cloudflare, Riot Games

If you’re using Stainless to generate SDKs, supporting additional languages becomes much more reasonable, with less marginal effort per new language. And I suspect that for many companies, landing even one big customer because you have an SDK in a language that matters to them would outweigh the cost and effort of generating and supporting a new SDK language.

When you really don’t need an SDK

As with all things in technology, the same approach won’t work in all situations. There are absolutely times in which it might not make sense to generate client SDKs. Here are a few conditions where that may be true:

Your API is very simple, with flat and uncomplicated data structures

Your API very rarely changes, so integrators don’t have to worry about using the latest features

Because of simple API shapes or slow-moving API changes, you’ve proven out through evals that LLMs can effectively use raw HTTP requests to interface with your API

Your API has only a few clients, like your mobile app and/or website, and the cost of duplicating or hand-writing “SDK” code is relatively low

There are definitely APIs so simple that an SDK would be overkill. But in 2026, the list of APIs that fit that description is starting to shrink rapidly, especially if you need AI agents to be able to interface with your services.

Conclusion

If you are building an API, and that API needs to be used by human developers or LLMs to quickly and correctly build integrations against your services, you probably need an SDK. An SDK with great DX and types that stay in sync with your API will be preferred over raw HTTP requests by many developers, and will enable agents to write code that integrates against your API.

To get started using Stainless to generate SDKs from your OpenAPI spec, check out the docs here and start building!