# liblab and Voxgig, compared

> SDK generation shaped as a release pipeline. Part of Postman since November 2025. Commercial SDK generation whose center of gravity is publishing rather than generating: version, changelog and push packages to npm, PyPI, Maven, and NuGet on every spec change. Generates and hosts an MCP server from the same specification. Acquired by Postman in November 2025. Published by Voxgig, which makes one of the two tools. Facts checked 28 September 2026.

**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 it 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.

## Facts

- Made by: liblab, part of Postman since November 2025
- License: Proprietary. Generated SDKs are yours
- Language targets: 6, plus Terraform
- Distinctive: Versioning, package publishing, a hosted MCP server
- Site: `liblab.com` (https://liblab.com)

## What liblab does that Voxgig does not

### 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

| | liblab | Voxgig |
| --- | --- | --- |
| License | Proprietary. Generated SDKs are yours | MIT. Generated SDKs are yours |
| Cost | Tiered subscription, quoted at the top | Free |
| Language targets | 6, plus Terraform | 23 language targets, 20 bundled plus Dart, Haskell and Lean from the langpack |
| Package publishing | Generated, versioned and published for you | Your repository and your CI |
| Terraform provider | Yes | No |
| MCP server | Yes, generated and optionally hosted by liblab | Yes, generated into your repository |
| Owner | Postman, since November 2025 | Voxgig 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.

- liblab: [`@saladtechnologies-oss/salad-cloud-sdk 0.9.0-alpha.17`](https://github.com/saladtechnologies/salad-cloud-sdk-javascript). The TypeScript SDK SaladCloud publishes on npm, generated with liblab 2.25.53.
- Voxgig: [`voxgig-sdk/saladcloud-sdk`](https://github.com/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. Source: https://github.com/SaladTechnologies/salad-cloud-docs

### What each SDK does

| | liblab | Voxgig |
| --- | --- | --- |
| Operations callable | 36 methods | 36 of 36 |
| Mock scenario on container groups | 1 of 4 steps right. Its Zod validation rejected the mock's responses, which break the definition's own schema | 4 of 4 right |
| Response validation | Zod, on every response | Not in this build. The opt-in validate feature checks payloads against the model's field types |
| Retries | Two retries on 408, 429 and 5xx, a fixed 150 ms apart | On 408, 425, 429, 500, 502, 503 and 504, honoring Retry-After |
| Timeouts | Client-wide, with no default and no per-call value | 30 seconds per attempt by default |
| Pagination | Helpers in the package that no operation uses | Page and cursor state carried between calls in `ctrl.paging`, with no iterator |
| Idempotency keys | None | Generated for every mutating call, and kept across its retries |
| Rate limits | 429 is on the retry list, but every operation turns a 429 into an error thrown without retry | A client-side token bucket, and Retry-After honored on 429 |
| Logging | None | Request and response logging, with auth headers redacted |
| Offline test mode | None | A mock transport seeded with your data, which the generated tests run on |
| Metrics | None | Per-operation counts and timings, with no OpenTelemetry |
| Cancellation | None beyond the timeout | A signal stops `stream()` between items. Only the timeout aborts a request in flight |
| Hooks | A build-time hook, not pluggable at run time | Custom features that hook every stage of a call |
| Errors | One ProblemDetails class for declared statuses, declared in the types but missing from the runtime exports | One error class per SDK, carrying the HTTP status and a `notFound` flag |

### What the code is

| | liblab | Voxgig |
| --- | --- | --- |
| Package | `@saladtechnologies-oss/salad-cloud-sdk` on npm, an alpha | Not published. You build it from the repository |
| TypeScript package size | 1.20 MB in 6 files, bundled | 1.47 MB in 300 files |
| Runtime dependencies | 1: `zod` | None |
| Languages from this build | TypeScript | TypeScript, Python, PHP, Go, Ruby and Lua, plus a Go CLI and a Go MCP server |
| Shape | A service per area, such as `containerGroups`, with positional arguments for path parameters | 14 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 |
| Types | A type and a Zod schema per model, for requests and responses | An interface per entity, from the response schema. Create takes the response type, so a TypeScript create needs a cast |
| Tests | Not run here: the comparison used the published package | 309 generated TypeScript tests pass, as do the generated Go, Python, Ruby, Lua, and PHP suites |

The same calls in each, in TypeScript. `@saladtechnologies-oss/salad-cloud-sdk 0.9.0-alpha.17`:

```ts
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`:

```ts
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](https://github.com/voxgig/apidef/issues/98)), and a container group instance is split across two entities, because its read answers only a 202 ([voxgig/apidef#111](https://github.com/voxgig/apidef/issues/111)).

The full scorecard, with the evidence for every row: https://github.com/voxgig-sdk/saladcloud-sdk/blob/main/COMPARISON.md

## 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. A correction changes the page and moves its checked date.

## First-party sources

- [liblab.com](https://liblab.com)
- [liblab's MCP generator](https://liblab.com/docs/mcp/howto-generate-mcp-with-liblab)
- [liblab's own announcement](https://liblab.com/blog/liblab-joins-postman)
- [Postman's announcement](https://blog.postman.com/postman-acquires-liblab/)

## The other comparisons

- [All SDK generator comparisons](https://voxgig.com/sdk/comparisons): the index, the method, and the wider field.
- [OpenAPI Generator](https://voxgig.com/sdk/comparisons/openapi-generator): The community generator most APIs have shipped an SDK from at least once.
- [Speakeasy](https://voxgig.com/sdk/comparisons/speakeasy): Commercial SDK generation whose generator became AGPL-3.0 open source in September 2026.
- [Fern](https://voxgig.com/sdk/comparisons/fern): SDKs and a documentation site from one definition. Part of Postman since January 2026.
- [Stainless](https://voxgig.com/sdk/comparisons/stainless): The generator behind many of the best-known AI SDKs. Its hosted product is winding down.
- [Cloudflare Forge](https://voxgig.com/sdk/comparisons/cloudflare-forge): Cloudflare's open-source generation pipeline, published on 28 September 2026.
- [APIMatic](https://voxgig.com/sdk/comparisons/apimatic): The longest-running commercial generator here, and the only one that converts between description formats.
- [Kiota](https://voxgig.com/sdk/comparisons/kiota): Microsoft's client generator, built so you do not need a separate SDK per API.
- [Hey API](https://voxgig.com/sdk/comparisons/hey-api): The TypeScript ecosystem's generator, with a Python generator in early development.
- [Voxgig SDK Generator](https://voxgig.com/sdk)