# Migrate from Stainless to Fern Fern is the long-term home for your SDKs. Our team migrates you within a week. Trusted by Square, Auth0, ElevenLabs, Adobe, Twilio, and Samsara. ## Built for the long haul Stainless is winding down. Speakeasy pivoted. Fern is backed by Postman with an extensive product roadmap to improve 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. - **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. ## What Square's engineering team says > 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 Fellman, Head of Engineering, Developer Platform, Square ## Evaluate against Speakeasy Teams pick Fern after side-by-side evaluations against Speakeasy. The Fern TypeScript SDK is compared against the Speakeasy TypeScript SDK below. | Category | Fern TypeScript | Speakeasy TypeScript | |---|---|---| | 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` 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. | Reference repos: Fern-generated [square-nodejs-sdk](https://github.com/square/square-nodejs-sdk) and Speakeasy-generated [cloudinary/analysis-js](https://github.com/cloudinary/analysis-js). ## Fern 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 **How long does a typical migration take?** Most teams cut over in 5 to 10 business days. Multi-spec or auth-heavy APIs take 2 to 3 weeks. A Fern engineer embeds with your team through the cutover. **Will my existing SDK consumers break?** No. We mirror your current SDK surface (class names, method signatures, error types) so published versions stay backward-compatible. **What about our custom code and Stainless extensions?** Send us your Stainless-flavored spec. We port x-stainless-* extensions to Fern equivalents. Custom code patches are preserved via Fern Replay. **Are the generators open source?** Yes. Every generator is Apache-2.0 licensed on GitHub. Fork, audit, or self-host the entire pipeline. **Do you support our language?** TypeScript, Python, Go, Java, C#, PHP, Ruby, Swift, and Rust. Each follows that language's idioms. **Can we self-host?** Yes. On-premise and self-hosted deployment for regulated industries. SOC 2 Type II, SLAs available. **Can we generate SDKs entirely on our infrastructure?** Yes. `fern generate --local` runs the pipeline on your machine or CI with no remote call. Works air-gapped, so nothing about your spec leaves your perimeter. **What spec formats and protocols does Fern support?** OpenAPI 3.1 and AsyncAPI as first-class inputs, plus gRPC and the native Fern Definition. Multiple specs merge into one SDK natively (Stainless accepts a single spec). Discriminated unions map to native language constructs and SSE gets typed streaming helpers across REST, WebSockets, and gRPC. **Do the generated SDKs have runtime dependencies?** TypeScript and Go ship with zero runtime dependencies. Smaller bundles, faster installs, and no supply-chain risk to audit. **What does ongoing support look like?** You get dedicated TypeScript, Java, and Python SDK engineers on committed hours, a shared Slack channel, and first-line triage on your public SDK repo's GitHub Issues. It's an ongoing partnership, not a one-time generator handoff. **Can we talk to existing Fern customers?** Yes. Ask us for introductions to reference customers at Square, Auth0, ElevenLabs, Adobe, Samsara, and Twilio. ## 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: - Read the full comparison: