Stainless joining Anthropic is good news for the OpenAPI tooling space — they have built a strong SDK generator and a public customer roster — but it does create a planning moment for the teams who depend on Stainless-generated SDKs and docs today. This post is the short, practical read on what to think about and what to do this quarter.
We are an independent company. Bloom is one option for teams that want to keep an OpenAPI-first workflow with a migration safety net, but the questions below are worth asking regardless of which destination you pick.
What we know
- Stainless announced it is joining Anthropic. The post is light on operational details but is clear on direction: more focus on Anthropic-aligned work going forward.
- Existing Stainless customers continue to have access to the dashboard, generation, and hosted Docs Platform as before.
- There is an official transition documentation set for the customers most affected.
What it doesn't change
- You own your OpenAPI spec, your
stainless.yml, the generated SDK repos, and the docs repo. None of that depends on Stainless running indefinitely. - Customers of your SDKs do not care which generator emitted the code. They care that the imports, methods, and behavior stay the same.
- A migration, if you choose one, is a workflow change, not a customer-facing change.
The questions worth asking now
- What is in the inventory? OpenAPI source,
stainless.yml, every SDK repo and its publish settings, the docs repo and any custom domain, README example endpoints, MCP host settings. - What ships next month? If you are mid-launch, the priority is to not break the launch. The migration can wait one quarter without harm in most cases.
- What would have to be true for a migration to be reversible? Same package names, same import paths, same auth env vars, same method shapes — at minimum. Anything that diverges is something your customers will have to change.
- Is the docs site dependent on hosted Stainless APIs? If yes, the docs migration is separate from SDK generation. Either change requires planning even if you keep both Stainless and a docs platform.
What a reversible migration looks like
Bloom's migration page and our checklist are written around the same principle: nothing reaches a customer until you approve. The practical shape is:
- Upload OpenAPI +
stainless.yml. - Generate replacement SDK and docs previews.
- Get a compatibility report against your current Stainless SDK — public surface (methods, errors, pagination, README examples) diffed line-by-line.
- Approve, then repo-sync. The cutover is reversible: keep the prior Stainless-generated package on the latest minor for a release cycle.
The parity table is the honest version of "what Bloom covers and what Bloom doesn't." Bloom ships TypeScript and Python today and matches Stainless on the docs, publishing, and migration-report axes. It doesn't yet cover Go, Java, Ruby, or .NET — if your customers depend on those, plan accordingly.
What to do this week
- Read the migration checklist and inventory the files in your repo.
- Skim the Bloom vs Stainless parity table — note the rows you cannot afford to lose.
- If you want a private preview run against your own spec, start a free 30-day trial — no credit card.
If you are not the decision-maker, the most useful thing you can do is forward this post and the inventory checklist to whoever is. The Stainless transition does not force a same-quarter migration; it does force a same-quarter inventory.
Other options to evaluate
We are not the only destination. The Stainless alternatives matrix ranks Bloom, Speakeasy, Fern, APIMatic, and OpenAPI Generator across SDK generation, docs, migration help, and pricing transparency. Use whichever fits — the inventory is more important than the destination.