The Stainless SDK generator wind-down

Stainless is winding down its hosted SDK generator. If you have SDKs in production that were generated by it, this page is an attempt to lay out what actually changed, what it forces you to decide, and what the realistic options are.

This page is written by Scalar, and Scalar sells an SDK generator, so read it with that in mind. Every factual claim about Stainless links to Stainless's own writing. Every claim about another generator links to that vendor's own documentation, pricing page, or repositories. We have tried to write the page we would want to read if we were the ones migrating, including the parts where somebody else is the better answer.

What is happening

On 18 May 2026, Stainless announced it is joining Anthropic:

"As we focus on Claude Platform capabilities and connecting agents to APIs, we'll be winding down all hosted Stainless products, including our SDK generator. Starting today, new signups, projects, and SDKs will not be available."

Three things in that sentence matter, and they are easy to run together:

It is all hosted products, not only the SDK generator. The Docs Platform is included.
New signups, projects, and SDKs closed on the day of the announcement. This was not a future-dated deprecation.
The generated code is yours. Stainless is explicit about this:

"As always, you own the SDKs you've generated to date, and have full rights to modify and extend them however you wish."

Stainless directs existing customers to app.stainless.com/transition. We cannot see that page from outside an account, so if you have one, read it before anything here.

What Stainless has not published is an end date for existing projects. The announcement covers new signups, projects, and SDKs. It does not say when — or whether — builds stop for projects that already exist. We are not going to guess at that on their behalf. If you are planning around it, treat the absence of a published date as a reason to move on your own schedule rather than as reassurance.

Research date: 16 August 2026. If Stainless has since published a timeline, this page is out of date and we would like to know — see the note at the bottom.

What it means if you are on Stainless today

Nothing breaks today. That is genuinely true, and it is also the thing that makes this easy to defer past the point where it is comfortable.

What keeps working:

Every package you have published. Your users keep installing exactly what they install now.
Your SDK repositories, under your organisation, on your registries.
Every line of generated and hand-written code in them. You own it.

What stops:

Regeneration. The next time you add an endpoint, change a response shape, or deprecate a field, nothing updates on its own.
Adding a language you have not already generated.
The Docs Platform, if you used it. Stainless stores those repositories in the stainless-sdks GitHub organisation rather than yours, and their own hosting guidance is that you fork the Astro project out and take on the repository, CI, deployment, and domain yourself — after which "your organization is fully responsible for the repository, CI configuration, deployment target, domain configuration, and other operational concerns."

So the real deadline is not Stainless's. It is your next API change. Between now and then, the cost of doing nothing is zero. After it, your SDKs and your API disagree, and the gap grows with every release.

How to evaluate the options

There is an obvious way to read this situation — "I have an OpenAPI document, every generator reads OpenAPI, so I can pick any of them" — and it is the thing that will cost you the most.

Your OpenAPI document was never the hard part. It is yours, it is portable, and it describes your API. What it does not describe is your SDK: which operations became which namespaces, what each method is called, which pagination scheme each list endpoint uses, what the client class is called, what your package is named in each language. Those decisions live in stainless.yml, and none of them are expressible in OpenAPI.

Regenerate from the specification alone with any tool, and you get a working SDK with a different public surface. New namespaces, new method names. That is a breaking change for everyone who has already written code against your package, and it is your users who absorb it.

So the question to ask each option below is not "does it generate good code". They mostly do. It is: can it reproduce the public surface my users are already calling?

The options

OpenAPI Generator

The default answer, and for a lot of teams the correct one. OpenAPI Generator is Apache-2.0, community-maintained, and ships 80 client generators covering languages nothing commercial will ever reach — Ada, Elm, Erlang, OCaml, R, Xojo.

Where it beats every commercial option, including Scalar: it costs nothing, it has no vendor attached, and nobody can wind it down. If the last three months have made you wary of depending on a hosted generator's continued existence, that is a legitimate conclusion to draw, and this is where it leads.

The honest cost: output is generated from Mustache templates and is rarely idiomatic in the way a Stainless SDK is. There is no stainless.yml equivalent, so your resource tree, method names, and pagination behaviour are yours to re-express through per-generator configuration and templates. Most teams that go this route end up owning a real amount of template and post-processing code. That is a maintenance commitment, not a one-time migration.

Speakeasy

The closest like-for-like replacement for the managed, turnkey experience. Speakeasy names TypeScript, Python, Go, Java, C#, PHP, Ruby, and Unity in its own README — "10 languages and counting" — alongside Terraform providers, CLIs, MCP servers, and contract tests. It has been in this category as long as Stainless was.

Where Speakeasy beats Scalar: Terraform provider generation. Stainless had a terraform target and Scalar does not have an equivalent. If you were generating a Terraform provider from your API description, Speakeasy is the direct answer and we are not going to pretend otherwise. They also generate MCP servers and contract tests, and their comparison and vendor-selection writing is the most thorough public material in the category — worth reading even though it is written by a competitor of ours, for the same reason you should read this page sceptically.

Disclosure: Scalar and Speakeasy work together. Speakeasy documents a Scalar integration that pipes their automated code samples into a Scalar-rendered reference. Read our assessment of them with that in mind too — in both directions.

Worth knowing: the free tier covers one SDK with up to 50 API methods, with a 14-day trial of the paid tier. Their pricing page currently leads with their MCP and AI products rather than a published SDK rate card, so expect to talk to sales for a number. Speakeasy configures through its own gen.yaml and workflow files; there is no stainless.yml import, so preserving your existing surface is manual work you will need to scope. Our fuller Speakeasy comparison goes through the rest — and is, again, written by us.

Fern

Fern was acquired by Postman in January 2026 and says the product and brand continue independently. Fern has published a pitch to Stainless customers and offers to help with the transition.

Where Fern beats Scalar: protocol breadth and generator openness. Fern accepts AsyncAPI, OpenRPC, and gRPC/Protobuf as SDK inputs, none of which Scalar takes today. fern-api/fern is Apache-2.0 with every language generator public, so you can read the code that produces your SDK. Scalar's generator is closed source. If either of those is your requirement, Fern is the better tool and the rest of this page does not change that.

Worth knowing: Fern's migration material is a commitment to help rather than a documented mechanism — as of writing it does not describe reading stainless.yml or reproducing your existing method names. Ask them directly how your surface is preserved before you commit. Fern's free SDK tier caps at 50 endpoints, and a long list of SDK features is Enterprise-only, priced per SDK and billed annually with no published rate. Our fuller Fern comparison goes through this in detail — and is, again, written by us.

APIMatic

The longest-running commercial generator in this category, and the one with the most legible pricing. APIMatic supports seven languages and publishes a rate card: $10/month for Lite (one language, 20 endpoints per API), $300/month per language on Basic, custom above that.

Where APIMatic beats Scalar: longevity and specification handling. They have been doing this since 2014, and API Transformer — their format conversion tooling — handles a wider range of input dialects and legacy Swagger 2.0 documents than most modern generators bother with. If your API description is old, hand-maintained, or in a format nobody else reads, that matters.

Worth knowing: per-language pricing gets expensive quickly, endpoint caps are low on the lower tiers, and there is no stainless.yml path.

liblab

liblab generates TypeScript, Python, Java, .NET, Go, PHP, and Terraform, configured through a liblab.config.json.

Where liblab beats Scalar: its hooks model. liblab lets you inject code at defined points in the request and response lifecycle, which survives regeneration cleanly — a good fit if your API needs client-side behaviour that is not expressible in OpenAPI. It also covers Terraform, which Scalar does not.

Worth knowing: as with the others, no stainless.yml import, and SDK pricing is not published as a rate card.

stainful

Worth knowing about even though it is not a product. stainlu/stainful is an MIT-licensed open source generator that reads your existing stainless.yml directly and runs locally with no SaaS involved.

Where it beats every option here including Scalar: it is free, it is MIT, it runs on your machine, and there is no company attached that can wind it down.

The honest limits: it generates Python only as of v0.4.0, and it is a young project — tens of stars, one maintainer, with a published gap list. It is not a like-for-like replacement for a multi-language SDK estate. But if you are Python-only, or you want a local escape hatch that consumes the config you already have, it deserves a look before you sign anything.

oagen

WorkOS published oagen alongside a survey of the landscape. It is a framework that parses OpenAPI into a resolved intermediate representation rather than a turnkey generator — you write the emitter. Relevant if you have concluded you want to own your generation pipeline outright and would rather not start from Mustache templates.

Scalar

Our answer, stated plainly so you can discount it appropriately.

Scalar generates TypeScript, Python, CLI, Go, Rust, Java, Kotlin, Swift, Ruby, PHP, C#, C++, and Dart. It is $100 per month per target, published, and the SDK lives in your repository under your package name — Scalar opens pull requests against it and never cuts tags on your behalf.

Scalar also builds MCP servers from the same OpenAPI document, with per-endpoint tool selection, stored authentication, and OAuth for people outside your team. We host these rather than generating a server you deploy yourself, which is the opposite trade to Speakeasy's: theirs is code you own and run, ours is an endpoint you configure and we operate. If running it yourself is the requirement, that is a point for them.

The specific reason to look at us in this situation is that Scalar reads stainless.yml as an input. That is not a general claim of superiority; it is one structural fact that happens to matter a great deal right now, and it is the subject of the next section.

Where we are behind: no Terraform or SQL target, no gRPC/AsyncAPI/OpenRPC input, and our generator is not open source. Of our targets, TypeScript, Python, Go, and the CLI are generally available; the rest are marked experimental. If your migration depends on one of the experimental ones, talk to us before you plan around it rather than after.

Terraform and SQL are on our roadmap. We are saying that as a fact about our plans, not as an answer to the gap: there is no ship date, and if you have a terraform target today you should go and read Speakeasy's material rather than wait on ours.

The `stainless.yml` compatibility story

This is the part worth being precise about, because "seamless migration" is not a claim anyone should accept without a key list.

Both configs describe the same kind of thing — a resource tree, targets, pagination schemes, client settings — which is why the mapping is mostly mechanical. The differences are real but nameable. Compare Stainless's config schema against Scalar's SDK configuration reference:

`stainless.yml`	Scalar	Notes
`resources` (`methods`, `models`, `subresources`)	`resources` (`methods`, `models`, `subresources`)	Direct. This is the part that keeps your users' call sites working.
`targets`	`targets`	Direct for shared languages. See the gaps below.
`environments`	`environments` + `environmentOrder`	Stainless treats the first entry as the default; Scalar makes the ordering explicit.
`client_settings`	`clientSettings`	Constructor options, auth values, default headers, env var names, timeouts, retries. Keys are camelCase in Scalar.
`pagination`	`pagination`	Scalar's types are `cursor`, `cursorId`, `cursorUrl`, `offset`, and `pageNumber`.
`query_settings`	`querySettings`	Array formats `comma`, `repeat`, `indices`, `brackets`; nested `brackets` or `dots`.
`multipart_settings`	`multipartSettings`	Direct.
`security` / `security_schemes`	`openapi.security` / `openapi.securitySchemes`	Same idea, different nesting.
`streaming`	`streaming`	Direct.
`settings`	`settings`	Both exist; the contents differ. Stainless uses it for licensing, Scalar for file headers and response unwrapping.
`organization`	`name`	Scalar takes the product name; the rest of Stainless's organisation metadata has no direct home.

Where it does not carry, specifically:

targets: terraform and targets: sql have no Scalar equivalent today. If you generated either, Scalar does not replace them. Both are on our roadmap with no ship date, so migrate as though they are not coming. Speakeasy and liblab both generate Terraform providers now.
openapi.transforms has no Scalar equivalent. Scalar's openapi key is for SDK-specific overrides — code sample languages, security scheme overrides — not for rewriting the input document. If you used transforms, take the transformed output as your input so both generators are looking at the same API. This is the single most common way a migration diff comes out wrong, because the document in your repository is not the document Stainless generated from.
edition. Stainless pins a config schema version; Scalar does not have the concept. Nothing to carry.
readme. Stainless's README example selection has no direct equivalent.
Naming convention. Stainless uses snake_case keys, Scalar uses camelCase. Cosmetic, but it is why a hand-diff of the two files looks more different than it is.

Scalar also adds keys Stainless had no counterpart for — diagnostics for gating a build on specification quality, ignoredEndpoints, customCasings, errors — which you can ignore entirely on day one.

One behaviour worth checking by hand. Stainless auto-paginates methods named list_* by convention, and requires paginated: true only for methods that break the naming pattern. Pagination that was implicit in your config is the first thing to verify in the generated output, not the last.

What a migration actually involves

The short version, for Scalar specifically:

Export your OpenAPI document — the transformed one, if you used openapi.transforms.
Take stainless.yml as-is from your repository. No conversion step.
Import both — Import config in the dashboard, or through the CLI.
Diff the API surface. Compare the generated api.md against your current SDK's api.md. Both list every method grouped by resource, so the diff tells you immediately whether your public surface survived. Check nested sub-resource method names, pagination on list endpoints, the client class name, and the environment variable your users pass credentials through.
Take over the pipeline. Uninstall the Stainless GitHub App, take ownership of the release workflows in .github/workflows, re-point registry tokens.

The full walkthrough, including custom code and the Docs Platform, is in the Stainless migration guide. If you want the product-to-product view rather than the wider field this page covers, Scalar vs Stainless puts the two generators side by side, including where Stainless was genuinely the stronger tool.

If you are not choosing Scalar

Most of the work is the same whoever you pick, and some of it is worth doing this week regardless of how long you take to decide.

Snapshot your current public surface now, while you can still regenerate it. An api.md, or a script that walks your published package and dumps every exported method signature. Without it you have no way to prove a migration was non-breaking, and it gets harder to reconstruct as the code drifts.
Find your hand-written code before you regenerate anything. Stainless merged custom code into generated files through a semantic three-way merge, so your edits are interleaved rather than held as a separate patch set. Every generator handles this differently; all of them handle it better if you know which files are affected.
Take the Docs Platform repository out of stainless-sdks now if you used it, even if you have not decided where docs go next. It is a fork and a CI setup, and it is strictly easier to do while the source is still there.
Ask every vendor the same question: how does my existing public method surface survive this? Ask for the answer as a mechanism, not as a commitment. "We will help you migrate" and "we read your existing config" are very different answers.
Decide about Terraform early. If you had a terraform target, that narrows the field before anything else does.
Do not treat "nothing is broken" as time. The clock started at your next API change, and only you know when that is.

Get help

If you want to talk it through — including if you end up somewhere else — book time with us or start free.

Researched on 16 August 2026, against Stainless's announcement and documentation on their own site, and against each other vendor's public documentation, pricing pages, and repositories as of that date. Stainless announced its wind-down on 18 May 2026 and its documentation may change or be withdrawn; vendor pricing and feature sets move. We have made a genuine effort to be accurate and to say where another tool is the better answer. If something here is wrong, out of date, or unfair to your product, open an issue and we will correct it — including if you work for one of the companies named above.

Migration

User Management