Fern — the API interface layer

Fern turns your code into every interface an agent or human needs to use your API — and keeps them all correct.

Built for agents first, humans second.

Jan 2025 Jun 2026

0% automated / agentic requests

0% human requests

Cloudflare, June 2026 — the first crossover in the internet's history, arriving 18 months ahead of schedule.

Read the vision

The Shift

Don't build yesterday's product.

5 websites a human visits to make one purchase

vs.

5,000 websites an agent visits doing the same job

The driver isn't scrapers — it's agentic AI, bots acting on a user's behalf. Agentic traffic went from roughly 1.7% of automated requests at the start of 2025 to a reported 8,000% growth by year's end.

The internet was architected around human attention. That assumption is now false.

Humans don't disappear from the loop — they move up it: approving, governing, trusting what the agents consume. But the primary consumer of an API interface is now a machine.

For API interfaces, this is decisive. The consumer of your docs, your SDK, and your API is increasingly a machine. It doesn't browse a beautiful page — it ingests context, imports a client, and executes calls. A product built to make interfaces nicer for humans is a product built for a shrinking share of the traffic.

We build the interface layer for a machine-majority internet — agents first, humans second.

The Problem

Every API has many interfaces. They keep multiplying — and drifting.

The spec is an interface for tools. Docs are an interface for humans and agents. SDKs are an interface for developers, CLIs for automation, MCP servers for LLMs. Service contracts are interfaces between teams; changelogs, examples, and agent-readable context are interfaces too.

Today each one is built and maintained by hand, out of band from the code it describes. So they drift.

code · v42 what's actually shipped

Spec v39 3 releases behind

Docs v37 describes last quarter's API

SDK v35 a version behind, silently

MCP server — hand-rolled once, forgotten

Agents consume interfaces directly

A stale SDK or an inaccurate spec means an agent silently generates broken integrations — a broken integration is silently lost API adoption you never see.

APIs depend on each other

Inside any company running more than a handful of services, one team's API change silently breaks another team's app — and nobody finds out until production.

Both problems share one root cause: interfaces are treated as artifacts you maintain instead of outputs you generate.

The Product

One interface layer, powered by one graph.

Connect your GitHub repos, and Fern maintains a live model of your entire API surface and every dependency between your services — the API Interface Graph — and from it generates and continuously verifies every interface your API needs.

We build the graph from code, not from a spec. Most organizations don't keep their API spec current — that's the very reason interfaces drift.

code → generated spec → docs · SDKs · CLIs · MCP · agent context → catalog → checked against every downstream consumer

Hover or focus a face

Each of the four is a projection of the same live graph — not a separate build.

Every repo connected makes the graph more complete, and a more complete graph makes every capability on top of it better. That compounding is the moat — not the individual features.

A Tuesday

Here's what that feels like, concretely.

A developer opens a PR that changes an endpoint.

Add trial_end to subscriptions #482

feat/trial-end → main · 3 files changed

fn

fern-bot bot

This changes the subscriptions API. I regenerated the spec, the TypeScript and Python SDKs, the docs and API reference, and the CLI command; I regenerated the MCP tool and drafted the changelog.

Two internal services still call the old request shape — this change is breaking, so I've opened fix PRs on both and flagged this one for review.

✓ spec regenerated ✓ TS + Python SDKs ✓ docs + API reference ✓ CLI command ✓ MCP tool ✓ changelog drafted ⚠ 2 consumers break — fix PRs opened

That single comment is every component of the product firing at once, from one graph. Everything the customer experiences is a projection of it:

What does this API look like?

Interfaces stay generated on every commit.

Who depends on this API?

Breaking changes get caught before they ship.

What services exist, and how do they connect?

A live internal API catalog.

The Core Loop

Generate on every commit — without drowning teams in review.

Auto-regenerating and requiring human approval on every change would just move the work from writing interfaces to reviewing them — worse, not better, for a team shipping fifty commits a day. The resolution is a tiered policy driven by change classification.

  "plan": "pro",
+ "trial_end": "2026-08-01"  optional
  "customer": "cus_123"

✓

Docs, SDK, and MCP update silently.

No review needed. New optional field, fully backward-compatible.

  "plan": "pro",
- "customer_id": "cus_123"
+ "customer": "cus_123"  renamed field

■

Everything stops. Human review required.

2 downstream services still call the old shape:

billing-worker · fix PR opened reporting-api · fix PR opened

A tool that cries "breaking change" on safe PRs gets turned off in a week — and it takes the auto-merge trust down with it.

So the first thing we ship is read-only: connect repos, build the graph, flag breaking changes with zero write access, and measure our own precision against what teams actually consider breaking. We earn the green-check trust before we ever gate a PR or open a fix.

The Four Faces

Each with its own evolution path and enterprise stickiness.

The product is unified, but each component has its own arc — one graph growing into the three scarce surfaces of the agent economy: discovery, execution, and routing.

Docs→the Catalogdiscovery interface

Today

Best-in-class hosted docs — reference, guides, API explorer, search, versioning, RBAC, localization, changelog, llms.txt — generated from the graph and kept in sync automatically. The human-facing front door and trust surface.

Evolution

Docs graduate from a site into a directory. Humans get a catalog in the spirit of an API network; agents get a machine-readable context source in the spirit of Context7. The entries aren't listings — they're live, verified interfaces generated from the graph.

Stickiness

Wired to custom domains, brand, SEO, and permissioned access — migrating is disruptive and visible. Once it's how engineers and agents discover services internally, it's the map the org navigates by.

SDKs→the Agent Toolsetexecution

Today

Typed, tested, multi-language SDKs (the consolidated Fern + liblab generator), versioned and published to package registries — plus generated CLIs.

Evolution

Agents don't want to hallucinate HTTP calls — they want deterministic commands against a service:

$ acme customers create --email jane@example.com

$ acme subscriptions create --customer cus_123 --plan pro

Fuzzy intent in, guaranteed-correct call out.

Stickiness

The strongest lock-in in the product. Docs migrate in an afternoon; a published SDK does not. Once customers depend on @yourcompany/sdk, switching is a company-wide migration for them — not a re-import for you.

MCP→the Execution / Routing Layerthe gateway

Today

An auto-generated, always-in-sync MCP server for the API — the newest and least-commoditized render, the one that makes "built for agents" concrete rather than a slogan.

Evolution

Natural language in, service action out — routed and executed through the deterministic SDK/CLI already generated:

NL intent→ Fern MCP tool→ SDK / CLI→ API call→ verified response

Anyone can build a fuzzy natural-language router. Only we route it to a deterministic, generated, verified tool.

Stickiness

Once agents reach services through Fern's MCP layer, Fern sits in the execution path with the governance — which agents may call which services, with what permissions and rate limits. A platform/security purchase, not a DevRel line item.

Graph & Guardrails→cross-boundary safetythe spine

Today

The dependency graph across REST / GraphQL / gRPC, and breaking-change prevention: on every PR, Fern checks the change against the graph, names the downstream service that would break and why, and can open a fix PR on the consumer.

Evolution

Extend the graph past the company line. Your service depends on Stripe; Stripe ships a breaking change; Fern warns you before it hits production. The bridge to a truly public network — and the biggest prize.

Stickiness

The deepest, because it's CI-native. Once Fern runs on every commit and gates every PR, a green check meaning "safe to ship" is load-bearing infrastructure. You don't rip out the thing standing between you and a production outage.

The arc across all four: discovery (docs) → execution tooling (SDK) → routing (MCP) — all resting on the graph & guardrails spine. One product, growing along four fronts.

Why Defensible

One graph under one product.

⁘

Every component is one asset, viewed differently

A competitor has to build the whole graph to match any single face of it.

⁘

Extraction from code is the hard moat

Code → spec, not a maintained spec, is what makes us work where interfaces actually drift.

⁘

CI position is sticky

Once Fern runs on every commit and gates every PR, it's infrastructure, not a doc site swapped out on a slow afternoon.

⁘

Published SDKs are switching cost

Once customers depend on your Fern-published packages, leaving is a company-wide migration.

⁘

Sync is structurally exclusive

"Never contradict each other" is impossible for anyone generating docs, SDKs, and MCP separately.

The incumbent docs players are already repositioning around AI. Our edge cannot be "AI docs." It's the graph and the code-first, multi-render, CI-native architecture that a docs-first company cannot bolt on.

Appendix 1 — Why "docs only" is a small market

A feature's TAM, not a company's.

The standalone documentation market is too small to be the destination, and the product layer is commoditizing underneath the incumbents.

Mintlify

~$10M ARR

ReadMe

~$8.4M

Redocly

~$7.8M

GitBook

~$3.9M ARR

Third-party estimates (Sacra, Growjo, Latka) — to be replaced with internal diligence, directionally clear.

Taken together, the core standalone docs competitors represent a sub-$40M revenue pool — excluding larger API-lifecycle suites.

Mintlify is the clearest signal in two directions at once. A reported 10x year, 10,000+ companies — but even the category leader's estimated ARR is ~$10M, and it no longer describes itself as a docs company. Its own 2025 review calls it "the infrastructure layer for how AI understands technical knowledge," and it now ships a self-updating-docs "Agent." The leader is fleeing the docs framing toward the agent framing.

Open-source has solved static generation — for free:

Docusaurus Fumadocs Astro Starlight

What they lack is the AI-native layer — automated generation, LLM-optimized output, sync with code — which is exactly where any defensible value now sits.

Static docs have become a marketing/trust surface — the storefront, not the operating system. The interface layer underneath the docs is the real market.

Appendix 2 — Product Sequence

One graph, four phases.

Consolidate and harden the foundation

Consolidate the SDK component (Fern + liblab) into one best-in-class multi-language generator — quality is a moat only if it's genuinely excellent.
Re-architect the docs component to support load and ensure future stability.

Exit criteria One SDK pipeline, a docs platform that won't buckle, and the internal spec/definition model every component renders from.

Generation completes; the graph is born

Build the MCP generator and hosting — the third render, completing "one spec → docs + SDK + MCP."
Launch the API graph builder (currently OpenBox) — code → spec extraction across REST / GraphQL / gRPC. Treat its accuracy as the primary risk.

Exit criteria All interfaces generated from one graph, on every commit, with the additive-vs-breaking classifier live — read-only first, to earn trust before gating.

Distribution and catalogs

Distribute docs to all Postman users — the reach that seeds coverage.
Build the public API catalog (the public API network) — discovery for humans and agents, populated by verified generated interfaces.
Build the internal docs directory (the service graph) — the private registry of every service a company runs. The standalone-defensible half of the catalog story.

Exit criteria Internal service graph shipping value at single customers; public catalog live with real coverage via Postman distribution.

The agent-economy graduations

Guardrails, full write mode. Graduate from read-only flagging to gating PRs and opening fix PRs on consumers. The deepest enterprise lock-in.
Agent Toolset. Graduate the SDK/CLI into the tool layer agents execute against — standalone-defensible, and it later earns the right to route.
Execution / Routing Layer. Natural language → deterministic generated tool. The crown, and the most contested surface — built only from strength.
Cross-boundary graph. Extend the dependency graph past the company line. The bridge to the fully public network — the biggest prize.

Sequenced After B/C prove classifier precision in the wild — you cannot gate on a classifier you haven't earned trust in.

The Bet

Fern is the API interface layer.

Connect your repos, and Fern turns your code into docs, SDKs, and an MCP server — generated and kept in sync on every commit — while catching any change that would break a service that depends on you.