SDK generator comparisons

liblab and Voxgig, compared

The tool that took the least glamorous part of shipping an SDK seriously first: not writing it, releasing it.

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 liblab on 14 November 2025. liblab was founded in 2022. Postman went on to acquire Fern, also compared on this site, in January 2026, so two of the tools here share an owner.

What liblab is#

liblab is a commercial SDK-as-a-service platform. It generates SDKs in TypeScript, Python, Java, C# and .NET, Go and PHP, plus a Terraform target. It is built around continuous integration: point it at a specification, and every change to that specification produces a regenerated, versioned, changelogged and published package.

Alongside the SDKs it generates documentation and embeddable code snippets, so the samples in your documentation come from the same run as the library they demonstrate. Since June 2025 it also generates an MCP server from the same specification, each SDK method becoming a tool, which liblab hosts at a public endpoint or hands you to run yourself.

Since November 2025 it has been part of Postman, and Postman has said liblab's technology is being integrated into its platform.

What liblab does that Voxgig does not#

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

Publishing as well as generating

Most generators hand you source and stop. liblab's product goes further down the pipeline: semantic versioning, changelogs, tags, and pushing the packages to npm, PyPI, Maven Central and NuGet on every spec change. This is the part teams consistently underestimate. Shipping an SDK is a release process with credentials, registries, deprecation policies and a support burden, not a build step, and a generator that only writes source has solved the easier half. Voxgig writes the source into your repository and leaves the release to you and your CI.

Hooks that survive regeneration

Per-language hook files sit outside the generated tree and let you add bespoke authentication, a response transform or a custom header without forking anything. Same instinct as Voxgig's components and features, arrived at from the other direction: liblab gives you an escape hatch beside the output, Voxgig gives you the generator's own extension points inside your repository.

An MCP server that liblab hosts for you

Generating an MCP server is one step. Running one that agents can reach is another, with a public endpoint, authentication and uptime to look after. liblab does both: the MCP tab of a project builds the server from the specification. liblab then hosts it at a public endpoint ready for Claude, Cursor or Copilot, or gives you the project to deploy yourself. Voxgig generates an MCP server into your repository and stops there, so where it runs is your problem. For a team with no infrastructure to put it on, hosting is the part that decides whether the server exists at all.

A Terraform target

One of two tools on this site that generate a Terraform provider today, the other being Speakeasy; Cloudflare names Terraform among the targets coming to Forge. If your API provisions anything, your larger customers will ask for a provider, and writing one by hand means learning resource and data-source schemas, plan and apply semantics, and import and state upgrades. It is a specialized job most API teams have nobody for. Voxgig does not generate a provider at all, so if you need one this is a complete reason to look here instead.

Postman distribution

Being inside Postman puts generated SDKs next to the collections and workspaces a large number of developers already work in. For an API team whose customers live in Postman, that is a distribution advantage no independent tool can match.

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.

liblabVoxgig
LicenseProprietary. Generated SDKs are yoursMIT. Generated SDKs are yours
CostTiered subscription, quoted at the topFree
Language targets6, plus Terraform23 language targets, 20 bundled plus Dart, Haskell and Lean from the langpack
Package publishingGenerated, versioned and published for youYour repository and your CI
Terraform providerYesNo
MCP serverYes, generated and optionally hosted by liblabYes, generated into your repository
OwnerPostman, since November 2025Voxgig Ltd, independent since 2018

One API, two SDKs#

SaladCloud publishes an SDK made with liblab. 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.

Voxgig

voxgig-sdk/saladcloud-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: SaladCloud's own definition, api-specs/salad-cloud.yaml in SaladTechnologies/salad-cloud-docs at commit 795066d: OpenAPI 3.1.0, 24 paths, 36 operations, MIT. Its source.

What each SDK does

liblabVoxgig
Operations callable36 methods36 of 36
Mock scenario on container groups1 of 4 steps right. Its Zod validation rejected the mock's responses, which break the definition's own schema4 of 4 right
Response validationZod, on every responseNot in this build. The opt-in validate feature checks payloads against the model's field types
RetriesTwo retries on 408, 429 and 5xx, a fixed 150 ms apartOn 408, 425, 429, 500, 502, 503 and 504, honoring Retry-After
TimeoutsClient-wide, with no default and no per-call value30 seconds per attempt by default
PaginationHelpers in the package that no operation usesPage and cursor state carried between calls in ctrl.paging, with no iterator
Idempotency keysNoneGenerated for every mutating call, and kept across its retries
Rate limits429 is on the retry list, but every operation turns a 429 into an error thrown without retryA client-side token bucket, and Retry-After honored on 429
LoggingNoneRequest 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
CancellationNone beyond the timeoutA signal stops stream() between items. Only the timeout aborts a request in flight
HooksA build-time hook, not pluggable at run timeCustom features that hook every stage of a call
ErrorsOne ProblemDetails class for declared statuses, declared in the types but missing from the runtime exportsOne error class per SDK, carrying the HTTP status and a notFound flag

What the code is

liblabVoxgig
Package@saladtechnologies-oss/salad-cloud-sdk on npm, an alphaNot published. You build it from the repository
TypeScript package size1.20 MB in 6 files, bundled1.47 MB in 300 files
Runtime dependencies1: zodNone
Languages from this buildTypeScriptTypeScript, Python, PHP, Go, Ruby and Lua, plus a Go CLI and a Go MCP server
ShapeA service per area, such as containerGroups, with positional arguments for path parameters14 entities, such as Container, with named match fields. The same path parameter is project_name in list and create and project_id in load and remove
TypesA type and a Zod schema per model, for requests and responsesAn interface per entity, from the response schema. Create takes the response type, so a TypeScript create needs a cast
TestsNot run here: the comparison used the published package309 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.

@saladtechnologies-oss/salad-cloud-sdk 0.9.0-alpha.17
import { SaladCloudSdk } from '@saladtechnologies-oss/salad-cloud-sdk'

const sdk = new SaladCloudSdk({ apiKey: process.env.SALAD_API_KEY })

const { data: groups } = await sdk.containerGroups.listContainerGroups('acme', 'demo')
const { data: group } = await sdk.containerGroups.getContainerGroup('acme', 'demo', 'web')
const { data: created } = await sdk.containerGroups.createContainerGroup('acme', 'demo', {
  name: 'web',
  container: { image: 'nginx:latest', resources: { cpu: 1, memory: 1024 } },
  autostartPolicy: true,
  restartPolicy: 'always',
  replicas: 1,
})
await sdk.containerGroups.deleteContainerGroup('acme', 'demo', 'web')
voxgig-sdk/saladcloud-sdk
import { SaladcloudSDK } from '@voxgig-sdk/saladcloud-sdk'

const client = new SaladcloudSDK({ apikey: process.env.SALADCLOUD_APIKEY })

// The same path parameter is project_name in list and create, and project_id
// in load and remove.
const groups = await client.Container().list({ organization_name: 'acme', project_name: 'demo' })
const group = await client.Container().load({ organization_name: 'acme', project_id: 'demo', id: 'web' })
// ContainerCreateData is the response schema, so without the cast TypeScript
// asks for id, create_time and current_state, which the server assigns.
const created = await client.Container().create({
  organization_name: 'acme',
  project_name: 'demo',
  name: 'web',
  container: { image: 'nginx:latest', resources: { cpu: 1, memory: 1024 } },
  autostart_policy: true,
  restart_policy: 'always',
  replicas: 1,
} as any)
await client.Container().remove({ organization_name: 'acme', project_id: 'demo', id: 'web' })

What building and running both found

  • liblab validates every response with Zod, and the mock's responses break the definition's own schema, so three of its four steps failed on validation. That is a limit of the mock, whose violations Prism reports itself.
  • liblab's error classes are declared in its types but missing from its runtime exports, so they cannot be imported to check an error against.
  • apidef took container, the container group's one object-valued property, for an envelope until 8.19.0, so Voxgig's load returned the inner container spec and its create nested the whole body under container. On 8.22.0 both read the group.
  • The TypeScript SDK threw Unexpected end of JSON input on SaladCloud's empty 202 until sdkgen 4.32.1, although the server had accepted the delete. On 4.32.1 an empty body is no body, and the Voxgig remove succeeds.
  • The same path parameter is project_name in Voxgig's list and create and project_id in its load, update, and remove (voxgig/apidef#98), and a container group instance is split across two entities, because its read answers only a 202 (voxgig/apidef#111).

The full scorecard, with the evidence for every row

Which one to choose#

Choose liblab when

  • You want no-touch SDK maintenance: spec changes in, published packages out, without anyone owning the release process.
  • You are a Postman shop and want the SDK story next to everything else you already run there.
  • You need a Terraform provider as well as SDKs. Voxgig does not generate one, and liblab and Speakeasy are the two tools on this site that do today.
  • Six languages covers your customers and you would rather rent the pipeline than build it.

Choose Voxgig when

  • You want to own the generator and the output, with no service in the path and nothing to renew.
  • You need more than six languages, or the Agent Skills and REPL surfaces. Both tools generate an MCP server; only Voxgig generates a CLI and a REPL.
  • You would rather your release pipeline was your own CI doing ordinary things, so that losing a vendor costs you a generator and not your ability to ship.

Limits of this comparison#

  • Whether liblab remains a standalone product or becomes a Postman feature is Postman's to say.
  • liblab's publishing pipeline is described from its documentation and product pages, not from an end-to-end run.
  • Publishing automation is a real advantage that Voxgig does not have an answer to. If that is your bottleneck, weigh it heavily.
  • The SDK pair is one small API, compared in TypeScript against a mock of its definition. The mock's responses break the definition's own schema, so liblab's validating SDK could not complete the scenario, and its score there is the mock's as much as its own.

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 liblab's own team carry the most weight.

liblab documentation#

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

liblab.comliblab's MCP generatorliblab's own announcementPostman'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.
  • FernSDKs and a documentation site from one definition. Part of Postman since January 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.
  • 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.