# Stainless

> A hosted generator of SDKs, Terraform providers, MCP servers and docs from OpenAPI. Closed to new signups and projects since May 2026, when Stainless joined Anthropic and began winding down its hosted products.

Source: https://apiguide.dev/tools/sdk-generation/stainless
Category: sdk-generation
Website: https://www.stainless.com
Pricing: freemium
Updated: 2026-10-17

## What is Stainless?

Stainless generated client SDKs from an [OpenAPI](/specifications/openapi) document, in languages including TypeScript, Python, Go, Java, Kotlin, Ruby, C# and PHP, along with Terraform providers, [MCP](/specifications/model-context-protocol) servers and a documentation platform from the same input. It ran as a hosted service, with a free plan for small APIs and paid plans above it.

On May 18, 2026, Stainless announced that it was joining Anthropic and winding down all of its hosted products, including the SDK generator. In its words: "Starting today, new signups, projects, and SDKs will not be available." Existing customers were directed to a transition page inside their account, and Stainless stated that customers own the SDKs generated to date, with full rights to modify and extend them.

Published packages and the SDK repositories already generated keep working. What goes away is regeneration: picking up changes to the OpenAPI document, adding a language, and the hosted documentation platform. Stainless has not published an end date for existing projects.

## Why use it in the API Lifecycle?

You should not start a new project on Stainless; it no longer accepts them. This page exists because many published SDKs were generated by it, and if you maintain one, its lifecycle question is now how to move off it.

* **The generated code is yours.** The SDK repository builds and publishes without the service. Nothing breaks the day regeneration stops.
* **But the SDK will drift.** Every change to the API after that day has to reach the SDK some other way: by hand, or by switching generator.

## Best Practices

* **Make sure you hold the SDK repositories.** If they live in an organization the vendor controls, fork or transfer them into your own now, along with any CI configuration that publishes them.
* **Choose a replacement while the API is quiet.** Generate the same OpenAPI document with [Speakeasy](/tools/sdk-generation/speakeasy), [Fern](/tools/sdk-generation/fern), [OpenAPI Generator](/tools/sdk-generation/openapi-generator) or [Kiota](/tools/sdk-generation/kiota) and compare the output against the existing SDK's public surface. See [SDK Generation](/guides/sdk-generation).
* **Treat the switch as a major version.** A different generator will name methods, errors and types differently. Unless you can reproduce the public interface exactly, release the new SDK as a new major version with a migration note rather than slipping breaking changes into a minor. See [Breaking Changes](/guides/breaking-changes).
* **Freeze hand edits until you have decided.** Patching the generated code by hand is reasonable for an urgent fix, but every patch is something the next generator will overwrite or you will have to port.
* **Learn the platform lesson.** When you pick the replacement, prefer one whose generator you can run yourself, or at least one whose output you fully own and can build without it.