The Stainless SDK generator wind-down

Last updated: September 2026

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. If you want a shorter, ranked shortlist rather than the full picture, see Stainless alternatives. 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.

First researched on 16 August 2026 and re-checked on 26 September 2026. As of the re-check, the announcement is unchanged and still gives no end date for existing projects. 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 lists 80 client generators as of September 2026, 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 few 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.

The biggest change since we first wrote this page: on 17 September 2026, as part of a partnership with Google, Speakeasy open-sourced its generator under AGPL-3.0 at speakeasy-api/openapi-generation, covering SDK generation in seven languages, CLI generation, and MCP server generation. The repository README says commercial customers supply a license token, and that generated output is licensed either AGPL-3.0-only or commercially. If AGPL obligations matter to you, read those terms with your lawyers before you plan around the open-source route.

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. Their generator is now also open source under AGPL-3.0, and Scalar's is closed source, so if reading or running the generator yourself is a requirement, that is a second point for them. 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 now leads with their "AI control plane" and shows a single Enterprise tier with tailored pricing 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: OpenRPC input and generator openness. Fern's pricing page lists AsyncAPI, gRPC, and OpenRPC as SDK protocols on its Enterprise plan. Scalar also takes AsyncAPI (currently experimental) and gRPC as SDK inputs, but not OpenRPC. 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. Its leave-Stainless page says OpenAPI Overlays and Fern Overrides replace Stainless configs, which means re-expressing your stainless.yml rather than reading it; as of September 2026 it does not describe reproducing your existing method names automatically. Ask them directly how your surface is preserved before you commit. Fern's free SDK tier covers Python and TypeScript for APIs up to 200 endpoints; other languages, custom code, and a long list of SDK features are 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 (up to five languages), and quoted Business and Enterprise tiers above that, with all seven languages on Business.

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, and endpoint caps are low on the lower tiers. APIMatic has published a Stainless migration guide (June 2026) that translates stainless.yml entries by hand into the OpenAPI document or its APIMATIC-META.json file, then reapplies custom code on regeneration. That is a documented process, but not a stainless.yml import.

liblab

liblab generates C#, TypeScript, PHP, Java, Go, and Python SDKs plus Terraform providers, configured through a liblab.config.json. On 14 November 2025 liblab announced it was joining forces with Postman, telling existing customers they could keep using the platform as before. Its homepage now describes liblab as part of Postman and routes sign-up through Postman, so the same Postman question you would ask about Fern applies here too.

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, with under a hundred GitHub stars as of September 2026 and 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, with the code on GitHub. 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, Go, and CLI targets (generally available), plus Java, Kotlin, Ruby, C#, PHP, Rust, Swift, Dart, and C++ (experimental). Every plan includes one SDK (one language target for one API), and additional SDKs are $150 per month each for up to 100 endpoints or $600 per month each for 101–250 endpoints, published. 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 OpenRPC input, and our generator is not open source, where Fern's is Apache-2.0 and Speakeasy's is now AGPL-3.0. AsyncAPI (experimental) and gRPC are supported as SDK inputs. 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. Retries, timeouts, and error classes are the second: your users' catch blocks depend on them. Our guides to SDK pagination and SDK error handling cover what to compare.

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. For a ranked shortlist of replacements, see Stainless alternatives, and for the general process of generating from an OpenAPI document with any tool, see how to generate an SDK from OpenAPI.

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.

Frequently asked questions

Is Stainless shutting down?

Stainless announced on 18 May 2026 that it is joining Anthropic and winding down all of its hosted products, including the SDK generator and the Docs Platform. New signups, projects, and SDKs closed on the day of the announcement.

When will existing Stainless projects stop building?

Stainless has not published an end date for existing projects. As of our re-check on 26 September 2026, the announcement still gives no timeline, so plan your move on your own schedule rather than waiting for one.

Do I still own the SDKs Stainless generated?

Yes. Stainless states that you own the SDKs generated to date and have full rights to modify and extend them. The code in your repositories keeps working; what goes away is the hosted pipeline that regenerates it.

Can Scalar read my stainless.yml?

Yes. Scalar imports stainless.yml as-is, and most keys map directly, including resources, targets, pagination, and client_settings. openapi.transforms, targets: terraform, and targets: sql have no Scalar equivalent today.

Which Stainless alternative generates Terraform providers?

Speakeasy and liblab both generate Terraform providers. Scalar does not; Terraform is on our roadmap with no ship date.

Learn: How to generate an SDK from OpenAPI · SDK pagination · SDK error handling
Docs: Stainless migration guide
Product: Scalar SDK Generator — reads your existing stainless.yml and publishes SDKs from your own repositories

Researched on 16 August 2026 and re-checked on 26 September 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

We wrote up the Stainless wind-down