Migrate from Stainless to Fern
Fern is the long-term home for your SDKs. Our team migrates you within a week. Trusted by enterprises.
30-minute call. Migration plan tailored to your API.
Built for the long haul
Stainless is winding down. Speakeasy pivoted. Fern is backed by Postman with an extensive product roadmap to improve our SDKs in multiple languages, Docs, and a CLI generator.
Generators are fully open source
Every generator is Apache-2.0 licensed on GitHub, so the pipeline is yours forever. You pay Fern for the hosted CI, registry publishing, and dedicated SDK engineers behind it.
Postman backing
Fern is backed by Postman, a company built entirely around API tooling. SDKs sit at the center of that roadmap, so we're here for the long haul.
SDKs are the core roadmap
Rust SDKs just shipped and a native CLI generator is on deck, with deeper protocol support and better ergonomics landing every quarter.
Why teams switch from Stainless
9+ languages from one spec
TypeScript, Python, Go, Java, C#, PHP, Ruby, Swift, and Rust. Stainless ships 8.
REST, WebSockets, and gRPC
Generate multi-protocol SDKs from one OpenAPI source. Stainless is REST only.
CLI in your CI, not a dashboard
Generation lives in a fern/ directory. CI opens a PR with updated SDKs on every spec change.
Docs included
Docs generate from the same spec so reference and code never drift. Includes Ask Fern, llms.txt, and MCP server.
On-premise and SOC 2 Type II
Self-hosted deployment for regulated industries. SOC 2 Type II, 99.9% uptime SLA.
We evaluated several SDK generators and Fern stood out for its clean, language-native, and thoughtfully architected code. The Fern team partnered with us every step of the way including OpenAPI improvements, alpha releases and launch announcements.
John FellmanHead of Engineering, Developer Platform, Square
Evaluate against Speakeasy
Teams pick Fern after side-by-side evaluations against Speakeasy. See what they picked us for.
| Category | Fern TypeScriptSquare SDK | Speakeasy TypeScriptCloudinary SDK |
|---|---|---|
| Dependencies | Zero-dependency TypeScript interfaces with tree-shakable serde. | Requires Zod as a peer dependency. Every model ships dual Zod schemas, adding ~13kB min+gzip before any SDK code. |
| Model output | Clean TypeScript types with no runtime scaffolding bolted on. | Models include schema machinery, $inboundSchema, $outboundSchema, $Outbound types, and standalone toJSON/fromJSON functions. |
| Response unions | Discriminated unions so consumers branch safely on response type. | Bare unions like SuccessResponse | AsyncAcceptedResponse with no discriminator. Consumers inspect properties manually. |
| Enum handling | Forward-compatible enums with unknown-value handling. New server values don't crash consumers. | Uses ClosedEnum for status and category enums. New server-side values can throw at runtime via Zod. |
| Test coverage | 146 auto-generated tests, including wire tests against a mock server. | No .test.ts, .spec.ts, or __tests__ files in the generated repo. |
| Boilerplate | Lean generated output. No deprecated scaffolding shipped on day one. | Heavy generated scaffolding. Example: source.ts takes 171 lines for two 3-line types. |
| Required params | Required params are validated at client initialization. | cloudName silently defaults to literal "CLOUD_NAME", producing valid-looking but broken URLs. |
| Retries | On by default: 2 retries with exponential backoff, jitter, and Retry-After support. | Defaults to strategy: "none", so users get no retry resilience unless they opt in. |
| Pagination | First-class pagination. Page<T> implements AsyncIterable for for await. | Cursor handling is manual. |
| Errors | Typed structured errors. Example: SquareError.errors includes typed category and code enums. | Returns raw body: string and leaks naming like data$ into the public API. |
| JSDoc examples | @example JSDoc on every method with runnable IDE snippets. | No @example tags. |
| Raw response access | .withRawResponse() is opt-in and returns an HttpResponsePromise that extends native Promise. | Result-style patterns and $inspect() concepts. |
| Naming consistency | Consistent generated naming conventions across resources. | Inconsistent AI vs Ai casing. data$ names bleed into the public API. |
| Auth plumbing | Auth surface is generated to match the spec. | Ships unused OAuth2 password-flow and OIDC scaffolding even for Basic-Auth-only APIs. |
| Additional features | Tree-shakeable subpackage exports, native BigInt serde, 8-runtime detection, webhook signature verification, structured pluggable logging. | Not highlighted. |
Square SDKFern is your SDK team
We partner with you to migrate and launch your SDKs.
- 1
Spec import and surface mirroring
Bring your existing OpenAPI spec, including Stainless extensions. We translate x-stainless-* annotations and mirror your SDK surface.
- 2
Fern Replay: custom code preserved
Custom-code patches replay on every regen, tracked in .fern/, visible in PR review.
- 3
Gradual migration at your pace
Ship old + new SDK at the same npm coordinate. OpenAPI Overlays and Fern Overrides replace Stainless configs.
- 4
Cut over and publish
Publish to npm, PyPI, Maven, and more. Old versions stay live until consumers migrate.
Common questions from teams evaluating Fern
Want the full feature-by-feature comparison? Read the Stainless to Fern blog post.
Get a tailored migration plan in 30 minutes
A Fern engineer walks you through your current spec, your SDK surface, and the exact cutover plan. No sales pitch, no slide deck.
Book a demo