SDK generator comparisons

Fern and Voxgig, compared

The only tool here whose documentation product is as strong as its SDK product. If docs are your real problem, this comparison probably ends early.

Published by Voxgig, which makes one of the two tools compared here. Facts checked against the first-party sources linked below. Corrections go to info@voxgig.com. Every page in this section follows the same scope and method.

Status

Postman announced its acquisition of Fern on 8 January 2026. The team joined Postman, and Fern says the product, brand, and roadmap continue unchanged. Postman had already acquired liblab, also compared on this site, in November 2025.

What Fern is#

Fern generates client libraries and a documentation site from one API definition. The CLI and the generators are Apache 2.0 on GitHub. Generation runs Fern's generator images in Docker, on Fern's cloud or on your machine, and local generation asks for a Fern API key to verify your organization. The self-hosted mode in which no definition leaves your infrastructure is an Enterprise feature. The commercial half is Fern Docs, a hosted documentation platform with custom domains, versioning, search and an interactive API reference wired to the same definition.

The SDK languages are TypeScript, Python, Go, Java, C# and .NET, PHP, Ruby, Swift and Rust, with C++ and Kotlin on request. The generated clients carry retries with backoff, automatic pagination, idempotency headers, webhook signature verification, server URL templating and per-language dynamic authentication. Since the acquisition Fern also emits Postman collections from the same definition. Since 2026 a CLI generator, in early access on request, produces a single statically linked Rust binary from an OpenAPI document or a GraphQL introspection schema. It has JSON output and structured help for agents.

Inputs are unusually broad: OpenAPI for REST and webhooks, AsyncAPI for WebSockets, Protobuf for gRPC, and OpenRPC, alongside the Fern Definition, a definition format of Fern's own that you can author directly instead of hand-maintaining OpenAPI.

Fern says more than two hundred companies use it, and names Square, Auth0, Adobe, Twilio and ElevenLabs among them. Cloudflare's Forge, compared on this site, drives Fern's generators for the SDKs it wraps. SDK pricing is a free tier limited to Python and TypeScript with an endpoint cap, a paid team tier, and an enterprise tier priced per SDK and billed annually. Fern Docs is priced separately, and the figures are on Fern's pricing page.

What Fern does that Voxgig does not#

Capabilities Fern has that Voxgig does not, in enough detail to evaluate them.

The documentation site is half the product

Almost every tool in this comparison generates a README and stops. Fern Docs is a real documentation platform: guides beside the API reference, versioned, searchable, on your own domain, generated from the same definition as the SDK so a new endpoint appears in both. Voxgig generates a README and a REFERENCE per SDK, and its docgen package adds a static reference site, a summary document and a slide deck that you host yourself, on GitHub Pages by default. Voxgig runs no documentation platform. Where the problem is the platform rather than the SDK itself, Fern addresses it and Voxgig does not.

Multi-protocol input

AsyncAPI for WebSocket surfaces and Protobuf for gRPC, alongside REST. Every other tool on this site, Voxgig included, is OpenAPI only. If part of what you ship is a streaming or gRPC interface, being able to generate all of it from one tool rather than two is a structural advantage, not a checkbox.

A definition format meant to be written by a human

OpenAPI is a description format that a great many teams end up authoring by hand, which is not what it was designed for. The Fern Definition is a smaller, friendlier format you write directly, and Fern emits OpenAPI from it. This removes a class of hand-written-YAML mistakes. The cost is a second source of truth to keep in step with what the server actually serves, which is the cost every intermediate definition layer carries.

Webhook signature verification, generated

A small feature that matters more than its size suggests. It is the thing integrators most reliably get wrong by hand, and getting it wrong is a security bug rather than an inconvenience. Voxgig does not generate it.

Open-source generators under a large owner

The generators being Apache 2.0 means the code survives a change of owner. The Postman acquisition adds resources behind it and moves the decision about its direction to a larger company. Which of those weighs more depends on your own risk position.

The generators other pipelines are built on

Fern's generators are Apache 2.0 container images that anyone can run. On 28 September 2026 Cloudflare published Forge with Fern's TypeScript, Python, Go, Java, PHP, C#, Ruby, Rust and Swift generators pinned by version inside it, producing the SDKs Forge's own packages wrap. The TypeScript SDK inside Cloudflare's cf CLI, 3,173 methods over the whole API, is Fern's TypeScript generator's output. A generator that another company adopts for an API of more than 3,500 operations has passed a test no comparison page can run. Voxgig's targets are run by Voxgig and its users, none of them at that scale.

Side by side#

No partial ticks and no asterisks. If a tool has a feature, the table says it has it. Where a row would need a paragraph to be true, it is a paragraph somewhere else on this page instead of a row here.

FernVoxgig
LicenseCLI and generators Apache 2.0. Hosted docs platform commercialMIT throughout
CostFree tier for Python and TypeScript with an endpoint cap, then a team plan, then per SDK. Docs platform priced separatelyFree
Account neededYes. Local generation verifies your organization with an API keyNo
InputsOpenAPI, AsyncAPI, gRPC, OpenRPC, Fern DefinitionOpenAPI
Language targets923 language targets, 20 bundled plus Dart, Haskell and Lean from the langpack
DocumentationA hosted documentation platformA README and REFERENCE per SDK, plus docgen's static reference site, summary and slide deck, hosted by you
MCP serverFor the documentation site, hosted by Fern. Not for the APIFor the API
CLI and REPL over your APIA CLI, in early access, as a Rust binary. No REPLBoth
OwnerPostman, since January 2026Voxgig Ltd, independent since 2018

One API, two SDKs#

Vapi publishes an SDK made with Fern. Voxgig built one from the same definition, and both were run against a mock of that definition on the same four steps: list, load, create, and remove. Voxgig's features are in the build and stay off until a client switches them on; the rows describe them switched on. Last measured 29 September 2026.

Fern

@vapi-ai/server-sdk 2.0.1

The TypeScript server SDK Vapi publishes on npm, generated with Fern from the same definition.

Voxgig

voxgig-sdk/vapi-sdk

Built on 29 September 2026 from the same definition: eight targets from one run. A repository to build from, not a published package.

The definition: Vapi's own OpenAPI definition, fern/apis/api/openapi.json in VapiAI/docs at commit 6ead80d: OpenAPI 3.0.0, 71 paths, 139 operations, MIT. Its source.

What each SDK does

FernVoxgig
Operations callable139 methods139 of 139
Mock scenario on assistants4 of 4 steps right, against a hand-written mock4 of 4 right, against the same mock
RetriesTwo retries on 408, 429 and 5xx, with exponential backoff and jitterOn 408, 425, 429, 500, 502, 503 and 504, honoring Retry-After
Timeouts60 seconds by default, client-wide or per request30 seconds per attempt by default
PaginationNone for this API. Paginated endpoints take page and limit and return a plain bodyPage and cursor state carried between calls in ctrl.paging, with no iterator
Idempotency keysNoneGenerated for every mutating call, and kept across its retries
Rate limitsRetry-After or X-RateLimit-Reset honored on 429, within the retry budgetA client-side token bucket, and Retry-After honored on 429
LoggingA logging option with levels, secrets redacted, silent by defaultRequest and response logging, with auth headers redacted
Offline test modeNoneA mock transport seeded with your data, which the generated tests run on
MetricsNonePer-operation counts and timings, with no OpenTelemetry
CancellationAn AbortSignal per request, merged with the timeoutA signal stops stream() between items. Only the timeout aborts a request in flight
HooksNo hook API. A custom fetch or fetcher, which the README calls break-glassCustom features that hook every stage of a call
ErrorsA class per status on 19 of the 139 endpoints, and a generic VapiError on the restOne error class per SDK, carrying the HTTP status and a notFound flag

What the code is

FernVoxgig
Package@vapi-ai/server-sdk on npmNot published. You build it from the repository
TypeScript package size9.68 MB in 10,563 files2.97 MB in 340 files
Runtime dependenciesNoneNone
Languages from this buildTypeScriptTypeScript, Python, PHP, Go, Ruby and Lua, plus a Go CLI and a Go MCP server
ShapeA client per resource, such as client.assistants, with request objects for path parameters24 entities, such as Assistant, each with the list, load, create, update and remove operations the API has
TypesAn interface per schema, nested objects includedAn interface per entity, from the response schema, with nested objects typed any. Create takes the response type, so a TypeScript create needs a cast
TestsNot run here: the comparison used the published package459 generated TypeScript tests pass, as do the generated Go, Python, Ruby, Lua, and PHP suites

The same calls in each, in TypeScript. Both samples type-check under strict mode against the SDK they name.

@vapi-ai/server-sdk 2.0.1
import { VapiClient } from '@vapi-ai/server-sdk'

const client = new VapiClient({ token: process.env.VAPI_TOKEN! })

const assistants = await client.assistants.list()
const assistant = await client.assistants.get({ id: 'asst_123' })
const created = await client.assistants.create({ name: 'Ada' })
await client.assistants.delete({ id: 'asst_123' })
voxgig-sdk/vapi-sdk
import { VapiSDK } from '@voxgig-sdk/vapi-sdk'

const client = new VapiSDK({ apikey: process.env.VAPI_APIKEY })

const assistants = await client.Assistant().list()
const assistant = await client.Assistant().load({ id: 'asst_123' })
// AssistantCreateData is the response schema, so without the cast TypeScript
// asks for id, orgId, createdAt and updatedAt, which the server assigns.
const created = await client.Assistant().create({ name: 'Ada' } as any)
await client.Assistant().remove({ id: 'asst_123' })

What building and running both found

  • Both SDKs called all four assistant operations correctly. The mock was hand-written because Prism could not load the definition in 20 minutes, so it checked the requests and not the response schema.
  • Voxgig's create types are the response schemas, and the generated README shows it: its example creates an assistant by passing an id, an orgId and two timestamps (voxgig/sdkgen#215).
  • Fern generates a type for each nested object. Voxgig types an entity's top-level fields and leaves nested objects as any, so TypeScript checks nothing inside an assistant's model, voice or transcriber (voxgig/sdkgen#220).
  • An entity named eval produced const eval in the README examples, which broke the TypeScript build on sdkgen 4.30.2. The fix shipped in 4.30.3, so the Voxgig SDK, built on 4.32.1, has it.
  • sdkgen sent every match field as a query parameter too until 4.31.0, so a Voxgig load asked for /assistant/asst_123?id=asst_123. On 4.32.1 a path parameter stays in the path.

The full scorecard, with the evidence for every row

Which one to choose#

Choose Fern when

  • You want SDKs and a documentation site from one definition and one vendor. It is the clearest reason on this page and it is a good one.
  • Your API has WebSocket or gRPC surface as well as REST.
  • You would rather author a compact definition format than hand-maintain OpenAPI YAML.
  • You want a CLI for your API as one static binary, published to npm, Homebrew and GitHub Releases on each release, and you can get into the early access.
  • Being inside Postman is a plus for you: distribution to a large developer audience, budget behind the roadmap, and an owner that is not going anywhere.

Choose Voxgig when

  • Being inside Postman is a risk for you. Two of the SDK generators in this comparison have the same owner, and acquisitions change roadmaps whatever the announcement says.
  • You need an MCP server over the API itself, or a REPL. Fern's MCP server answers questions about your documentation, and its CLI generator is in early access on request.
  • You want the entire toolchain MIT, including the parts that are commercial elsewhere, and generation that runs with no account.
  • You need more than the nine languages Fern targets, or you need one it does not have. Voxgig has 23 language targets, and adding another is a supported extension rather than a feature request.

Limits of this comparison#

  • The product changed owner in January 2026. Where it goes from here is for Postman and Fern to say.
  • Fern Docs has no Voxgig equivalent, and the comparison table cannot express that asymmetry in a row.
  • The docs platform is described from Fern's own documentation, not from use.
  • The CLI generator is in early access and is described from Fern's documentation, not from use.
  • The SDK pair is one API, compared in TypeScript. Prism could not load Vapi's definition, so the scenario ran against a hand-written mock of the four assistant operations that checks method, path, auth and a JSON body, and not the schema. Both SDKs passing it says less than a pass against the definition would.

Corrections go to info@voxgig.com or an issue on the generator repository. A correction changes the page and moves its checked date; corrections from Fern's own team carry the most weight.

Fern documentation#

First-party sources for the claims on this page. Where they disagree with it, they are the authority.

buildwithfern.comFern on GitHubFern's CLI generatorFern pricingFern's own announcement of the acquisitionPostman's announcement

The other comparisons#

  • OpenAPI GeneratorThe community generator most APIs have shipped an SDK from at least once.
  • SpeakeasyCommercial SDK generation whose generator became AGPL-3.0 open source in September 2026.
  • StainlessThe generator behind many of the best-known AI SDKs. Its hosted product is winding down.
  • Cloudflare ForgeCloudflare's open-source generation pipeline, published on 28 September 2026.
  • APIMaticThe longest-running commercial generator here, and the only one that converts between description formats.
  • liblabSDK generation shaped as a release pipeline. Part of Postman since November 2025.
  • KiotaMicrosoft's client generator, built so you do not need a separate SDK per API.
  • Hey APIThe TypeScript ecosystem's generator, with a Python generator in early development.

All comparisons, the ground rules, and the wider field

Read the generated code#

The generator is MIT and open, and the catalog holds 600+ generated SDKs readable without installing anything.

Voxgig SDK GeneratorTalk to Voxgig

Get the Voxgig dispatch

Short notes on building SDKs, CLIs, MCP Servers, and REPLs for API-first teams, plus the occasional Fireside episode pick.

By signing up you agree to our Terms of use.