Fern
Fern (acquired by Postman) · Coding
Fern is a developer tool that turns your API definition into production-ready SDKs and a hosted documentation site. Feed it an OpenAPI spec, a GraphQL schema, or its own definition format, and it generates client libraries in multiple languages plus a docs site with search, an API explorer, and AI features. It targets teams that want their API reference and client libraries to stay in sync without hiring a dedicated docs engineer.
About Fern
What Is Fern
Fern sits between your API definition and everything developers need to use it. As an API documentation generator and SDK builder, it works from a single source. Instead of hand-writing a Python client here and a TypeScript client there, you describe the API once and let Fern produce the SDKs, the reference docs, and the CLI from the same source. When the API changes, you re-run generation and every language picks up the update.
The core pitch is consistency. Most API teams end up with docs that drift from the real endpoints and SDKs that feel foreign in each language. Fern treats the API definition as the single source of truth, so the generated output stays aligned by construction. The company behind it was acquired by Postman, which folded the same idea into a broader API lifecycle toolchain.
The main limit is scope. Fern is built for teams that already own an API definition and maintain it in version control. If you don't have a spec, or you want a no-code page builder for marketing content, this isn't the right tool. The free tier also caps pages and AI credits, so larger docs sites hit paid territory quickly. No spec, no Fern.
Getting Started
- Sign up at buildwithfern.com and create a project in the dashboard, or scaffold one locally with the Fern CLI.
- Add your API definition to the project, either an OpenAPI spec, an AsyncAPI or GraphQL file, or a Fern definition written in YAML.
- Configure
docs.ymlto set your navigation, domain, and theme so the generated site matches your brand. - Run
fern generateto build SDKs and docs, and preview the output locally before publishing. - Publish to your custom domain or subpath, then wire up CI so the docs and SDKs rebuild on every API change.
Product Information
A quick look at Fern's pricing, supported platforms, and performance.
Best for
The users, tasks, and scenarios where this tool fits best.
Users
- Backend and platform engineers who own an API definition and want client libraries without hand-writing each one
- Developer experience teams that need a hosted reference site that stays in sync with the spec
- Startups shipping a public API who lack a dedicated technical writer
Tasks
- Generating idiomatic SDKs in TypeScript, Python, Java, Go, and other languages from a single spec
- Publishing an API reference site with search, an API explorer, and version switching
- Keeping docs and client libraries updated through CI on every API change
Scenarios
- A team adding its first public API and needing docs plus SDKs at the same time
- A platform group replacing a patchwork of auto-generated clients that feel foreign in each language
- An AI-forward team that wants its docs readable by coding agents through an MCP server and llms.txt
Key features
Multi-Language SDK Generation
Fern builds client libraries designed by language specialists rather than a generic template. The generated SDKs carry strong types, inlined documentation, and familiar error handling, so a Python developer and a TypeScript developer each get something that feels native. An OpenAPI SDK from a generic tool rarely feels this polished. That matters because developers adopted the switch from a generic generator specifically to escape complaints about awkward, hard-to-use clients.
Docs as Code
Your documentation lives in your repository like the rest of your codebase. Changes go through Git, reviewers see diffs in pull requests, and any coding agent can draft or update content. Teams that already treat infrastructure as code tend to find this workflow natural, and it removes the copy-paste step that usually lets docs fall behind an API. It just fits. No more stale pages.
AI Chat Grounded in Your Docs
Built-in AI chat lets readers ask questions and get answers pulled from your documentation. Because the answers are grounded in your content, they avoid the generic responses that come from a model answering from general knowledge. For readers stuck on a specific endpoint, that's the difference between a useful answer and a plausible-sounding one. No more guessing.
MCP Server and llms.txt
Fern exposes your docs and API through a Model Context Protocol server, and ships clean Markdown with an auto-generated llms.txt file. Together these make your API queryable by AI tools and coding agents that can read structured docs. If your users build with AI assistants, this is a practical way to let those assistants look things up in real time.
Broad Protocol and Spec Support
Fern accepts REST, WebSockets, and GraphQL, plus AsyncAPI and gRPC protocols. On the spec side it reads OpenAPI, OpenAPI Overlays, OpenAPI Arazzo, AsyncAPI, gRPC, GraphQL, OpenRPC, and its own definition format. That range means most teams can point Fern at the spec they already have instead of rewriting it. Point it and go.
Customization and Publishing
The free tier includes a custom domain and subpath, and paid plans add custom CSS, JavaScript, and React components along with custom layouts and design-system integration. You can also set up preview links, SEO optimizations, and password protection for private docs, so the reference site can match both your brand and your access rules. It scales up when you need it.
Pros and cons
Pros
- One API definition yields SDKs in many languages plus a hosted docs site, cutting duplicate work
- Docs-as-code workflow keeps the reference in version control and reviewable through pull requests
- Built-in AI chat, an MCP server, and llms.txt make the docs useful to both people and agents
- Free tier includes a custom domain, 1,000 pages, and 250 AI credits, enough to test the full flow
- Enterprise options cover SSO, SCIM, self-hosting, and an uptime SLA for regulated teams
Cons
- Requires a maintained API definition, so teams without a spec must write and own one first
- The free plan caps pages, page generations, and AI credits, which stops larger sites cold
- Advanced customization like custom React and design-system integration sits behind enterprise pricing
- Pricing above the free tier is quote-based, so budgeting needs a sales conversation
Frequently asked questions
Fern generates client SDKs and a documentation site from a single API definition. You describe the API once, and Fern produces the SDKs, reference docs, and a CLI, then keeps them aligned when the API changes.
Related content
Explore related tools, skills, and articles for Fern.
Fern Alternatives
Forefront
Forefront · CodingForefront is a web platform for building with open-source AI. It lets you fine-tune leading open-source language models on your own data, evaluate how they perform, and run them through an API or export them to host yourself. Developers who want the convenience of a closed-source platform but insist on owning their models and data are the target audience here.
Startkit
StartKit.AI · CodingStartkit is a boilerplate for building AI SaaS and AI wrapper products. Think of it as an AI startup boilerplate with the boring parts already wired up: authentication, Stripe and Lemon Squeezy payments, usage limits, transactional email, and an AI API starter that talks to OpenAI, Anthropic, Groq, or Llama. You clone the repo, set your price, and start on the part of your product that people actually pay for. It's Next.js under React and Tailwind, so most of the boilerplate code already feels familiar.
Testim
Tricentis · CodingTestim is an AI-powered test automation platform for building and running end-to-end tests across web, mobile, and Salesforce applications. It leans on machine learning to keep tests stable when an interface changes, so teams spend less time fixing broken selectors. Not bad for an automated testing tool you can start using today. You create tests by recording actions in a browser, then optionally add JavaScript when you need more control. It's a solid pick for busy QA teams.