Migrate from liblab CLI to Postman CLI

This guide walks you through migrating your SDK generation workflow from the liblab CLI to the Postman CLI. The SDK generation capabilities you relied on in liblab are now built into the Postman platform — the core config format, supported languages, and customization options remain the same.

Installation
Authentication
- Interactive login
- Long-lived tokens for CI/CD
Configuration Migration
Command Migration
CI/CD Pipeline Migration
- Environment variable
- GitHub Actions example
What Has Changed

Installation

Uninstall the liblab CLI and install the Postman CLI in its place.

# Remove liblab
npm uninstall -g liblab

# Install Postman CLI
npm install -g postman-cli

Verify the installation:

postman --version

Authentication

liblab CLI	Postman CLI
`liblab login`	`postman login`
`liblab logout`	`postman logout`

The liblab CLI used an Auth0 device-flow browser login. The Postman CLI authenticates using your Postman API key. Run postman login and follow the prompts, or set the POSTMAN_API_KEY environment variable directly.

Long-lived tokens for CI/CD

In liblab, you created dedicated CI tokens with liblab token create. In Postman, you use a Postman API key generated from your Postman account settings.

liblab CLI	Postman CLI
`export LIBLAB_TOKEN=<token>`	`export POSTMAN_API_KEY=<key>`
`liblab token create <name>`	Generate a key in Postman account settings
`liblab token list`	View keys in Postman account settings
`liblab token revoke <name>`	Revoke keys in Postman account settings

Configuration Migration

File location

The biggest structural change is where the SDK configuration lives.

	liblab CLI	Postman CLI
File	`liblab.config.json` (repo root)	`.postman/config.json`
Config location	Top-level object	Under the `sdk` key

The postman sdk init command scaffolds the new file for you:

postman sdk init

This creates .postman/config.json with a skeleton sdk key that you can populate from your existing liblab.config.json.

Backward compatibility

The Postman CLI will silently fall back to liblab.config.json in the current directory if .postman/config.json is absent. This means your existing repos will continue to work during the migration window without any changes. However, we recommend migrating to .postman/config.json before July 31.

Config key mapping

Most config fields migrate directly — you move them from the root of liblab.config.json into the sdk key of .postman/config.json. The table below covers all fields.

Root-level fields

liblab.config.json field	.postman/config.json sdk key	Notes
`sdkName`	`sdkName`	Identical
`sdkVersion`	`sdkVersion`	Identical
`apiName`	`apiName`	Identical
`apiVersion`	`apiVersion`	Identical
`baseUrl`	`baseUrl`	Identical
`languages`	`languages`	Identical. Supported values: `java`, `python`, `typescript`, `csharp`, `go`, `terraform`, `swift`, `php`, `mcp`
`auth`	`auth`	Identical. Values: `apikey`, `basic`, `bearer`, `custom`, `oauth`
`createDocs`	`createDocs`	Identical
`docs`	`docs`	Identical. Values: `api`, `snippets`, `enhancedApiSpec`
`customizations`	`customizations`	Identical (see sub-fields below)
`languageOptions`	`languageOptions`	Identical (see sub-fields below)
`workflows`	`workflows`	Identical
`analytics`	`analytics`	Identical
`specFilePath`	(removed — becomes CLI argument)	See Command Migration
`liblabVersion`	(removed)	Stripped automatically; no action needed
`publishing`	(removed)	Use `--pr` flag and integration settings instead
`validationsToIgnore`	(not supported)	Remove from config
`mcp.generate`	(removed)	Add `"mcp"` to the `languages` array instead
`integrations`	(not supported)	Remove from config
`liblabConfigVersion`	(removed)	Remove from config

customizations sub-fields

All customizations sub-fields are supported with the same names and structure:

Field	Supported
`authentication` (apiKey, basic, bearer, custom, oauth)	Yes
`documentation`	Yes
`devContainer`	Yes
`generateEnv`	Yes
`environments`	Yes
`license`	Yes
`retry`	Yes
`responseHeaders`	Yes
`endpointCustomizations`	Yes
`hookDependencies`	Yes
`deprecatedOperations`	Yes
`multipleResponses`	Yes
`buildAllModels`	Yes
`readme`	Yes
`includeOptionalSnippetParameters`	Yes
`refreshToken`	Yes
`environmentVariables`	Yes

languageOptions sub-fields

All language-specific options are supported with the same names:

Language	Supported
`python`	Yes
`typescript`	Yes
`go`	Yes
`java`	Not yet
`csharp`	Not yet
`php`	Not yet
`terraform`	Not yet
`mcp`	Not yet

The liblabVersion key inside language options (e.g. languageOptions.python.liblabVersion) is stripped automatically.

Before and after example

Before — liblab.config.json (repo root):

{
  "sdkName": "petstore-sdk",
  "apiVersion": "1.0.0",
  "apiName": "Petstore API",
  "sdkVersion": "1.0.0",
  "specFilePath": "https://petstore.swagger.io/v2/swagger.json",
  "liblabVersion": "2",
  "languages": ["typescript", "python", "go"],
  "auth": ["bearer"],
  "createDocs": false,
  "customizations": {
    "devContainer": true,
    "generateEnv": true,
    "license": { "type": "MIT" },
    "retry": {
      "enabled": true,
      "maxAttempts": 3,
      "retryDelay": 150
    },
    "authentication": {
      "access": { "prefix": "Bearer" }
    }
  },
  "languageOptions": {
    "python": {
      "pypiPackageName": "petstore-sdk",
      "githubRepoName": "petstore-python-sdk",
      "sdkVersion": "1.0.0",
      "liblabVersion": "2"
    },
    "typescript": {
      "npmName": "petstore-sdk",
      "npmOrg": "@my-org",
      "bundle": true,
      "githubRepoName": "petstore-typescript-sdk",
      "sdkVersion": "1.0.0",
      "liblabVersion": "2"
    },
    "go": {
      "goModuleName": "github.com/my-org/petstore-go-sdk",
      "githubRepoName": "petstore-go-sdk",
      "sdkVersion": "1.0.0",
      "liblabVersion": "2"
    }
  },
  "publishing": {
    "githubOrg": "my-org"
  }
}

After — .postman/config.json:

{
  "schemaVersion": "1",
  "workspace": {},
  "entities": {},
  "sdk": {
    "sdkName": "petstore-sdk",
    "apiVersion": "1.0.0",
    "apiName": "Petstore API",
    "sdkVersion": "1.0.0",
    "languages": ["typescript", "python", "go"],
    "auth": ["bearer"],
    "createDocs": false,
    "customizations": {
      "devContainer": true,
      "generateEnv": true,
      "license": { "type": "MIT" },
      "retry": {
        "enabled": true,
        "maxAttempts": 3,
        "retryDelay": 150
      },
      "authentication": {
        "access": { "prefix": "Bearer" }
      }
    },
    "languageOptions": {
      "python": {
        "pypiPackageName": "petstore-sdk",
        "githubRepoName": "petstore-python-sdk",
        "sdkVersion": "1.0.0"
      },
      "typescript": {
        "npmName": "petstore-sdk",
        "npmOrg": "@my-org",
        "bundle": true,
        "githubRepoName": "petstore-typescript-sdk",
        "sdkVersion": "1.0.0"
      },
      "go": {
        "goModuleName": "github.com/my-org/petstore-go-sdk",
        "githubRepoName": "petstore-go-sdk",
        "sdkVersion": "1.0.0"
      }
    }
  }
}

Key changes from the before/after:

The entire config is nested under "sdk": { ... } inside .postman/config.json.
specFilePath is removed — the spec or collection is now passed as an argument to postman sdk generate.
liblabVersion fields (root and inside languageOptions) are removed.
publishing is removed — configure PR targets via --pr flag and Postman integrations.

Command Migration

Build / Generate

The core SDK generation command changes as follows:

liblab CLI	Postman CLI
`liblab build`	`postman sdk generate <idOrPath>`

The <idOrPath> argument replaces specFilePath from the config file. It accepts:

A Postman Collection ID or Specification ID (UUID format) — builds are tracked in Postman Cloud.
A local file path to a collection (.json) or specification (.json, .yaml, .yml) — one-off build, not tracked in Postman Cloud.
A URL to a publicly accessible collection or specification — one-off build, not tracked in Postman Cloud.

# liblab (spec path was in config)
liblab build

# Postman — using a Postman Specification ID
postman sdk generate 12345-abcde-67890

# Postman — using a local OpenAPI file (one-off, equivalent to specFilePath)
postman sdk generate ./openapi.yaml

# Postman — using a URL (equivalent to a URL specFilePath)
postman sdk generate https://petstore.swagger.io/v2/swagger.json

Flag mapping

liblab build flag	postman sdk generate flag
`-l <language>`	`-l, --language <languages...>`
(no equivalent)	`--all` (generate all supported languages)
`--liblab-config <path>`	`--config <path>`
`-y, --yes`	`-y, --yes`
`--skip-validation`	(not needed — validation is handled server-side)
`--pr`	`--pr`
`-o, --org`	(configure via Postman integrations)
`-p, --platform`	(configure via Postman integrations)
(no equivalent)	`-o, --output-dir <path>` (default: `./sdks`)
(no equivalent)	`--name <name>`
(no equivalent)	`--sdk-version <version>`
(no equivalent)	`--verbose`
(no equivalent)	`--log-level <warn\|info>`

Init

# liblab
liblab init

# Postman
postman sdk init

postman sdk init creates or updates .postman/config.json with a skeleton sdk block. Use --yes to overwrite an existing sdk key.

Validate

The liblab CLI had a standalone liblab validate command. In the Postman CLI, spec validation happens automatically during SDK generation server-side. There is no separate validate command.

Pull Requests

# liblab — create PRs after build
liblab build --pr

# Postman — create PRs after generation
postman sdk generate <idOrPath> --pr

Configure the target repositories through Postman integrations rather than via publishing.githubOrg in the config.

Hooks

liblab hooks add / liblab hooks remove have no direct equivalent in the Postman CLI. Hook dependencies can still be declared in customizations.hookDependencies in the config.

CI/CD Pipeline Migration

Environment variable

# Before
export LIBLAB_TOKEN=<your-liblab-token>

# After
export POSTMAN_API_KEY=<your-postman-api-key>

GitHub Actions example

Before:

- name: Generate SDKs
  run: liblab build -y
  env:
    LIBLAB_TOKEN: ${{ secrets.LIBLAB_TOKEN }}

After:

- name: Generate SDKs
  run: postman sdk generate ./openapi.yaml -y
  env:
    POSTMAN_API_KEY: ${{ secrets.POSTMAN_API_KEY }}

If you were passing a specFilePath via config, move that path to the CLI argument as shown above (or use a Postman Specification ID if you have your spec hosted in Postman).

What Has Changed

Removed features

liblab feature	Status in Postman CLI
`liblab validate` (standalone)	Not available — validation runs server-side during generation
`liblab token create/list/revoke`	Replaced by Postman API keys in account settings
`liblab change-password`	Managed via Postman account settings
`liblab invite`	Managed via Postman team settings
`liblab bundle` / `liblab merge`	Not available
`liblab publish`	Not available — publishing is handled via SDK repository integrations
`publishing` config key	Not supported — configure via Postman integrations
`validationsToIgnore` config key	Not supported — remove from config
`mcp.generate` config key	Use `"mcp"` in the `languages` array instead
`integrations` config key	Not supported — remove from config
`liblabVersion` config key	Stripped automatically — safe to remove
`LIBLAB_TOKEN` env var	Replaced by `POSTMAN_API_KEY`
`LIBLAB_ENVIRONMENT` env var	Not applicable

Output directory

The liblab CLI wrote generated SDKs to .liblab/ by default. The Postman CLI writes to ./sdks by default. Override with --output-dir:

postman sdk generate ./openapi.yaml -l typescript --output-dir .liblab/

Config file auto-discovery order

The Postman CLI looks for config in this order:

Explicit --config <path> flag
.postman/config.json in the current directory (uses the sdk key)
liblab.config.json in the current directory (treated as a legacy standalone SDK config — this fallback will be removed in a future release)

Need help?

If you have questions about migrating, check the Postman SDK Generator documentation or reach out through your usual Postman support channels.

Table of Contents​

Installation​

Authentication​

Interactive login​

Long-lived tokens for CI/CD​

Configuration Migration​

File location​

Config key mapping​

Root-level fields​

customizations sub-fields​

languageOptions sub-fields​

Before and after example​

Command Migration​

Build / Generate​

Flag mapping​

Init​

Validate​

Pull Requests​

Hooks​

CI/CD Pipeline Migration​

Environment variable​

GitHub Actions example​

What Has Changed​

Removed features​

Output directory​

Config file auto-discovery order​

Need help?​

Table of Contents