Postman CLI Release Notes

What’s New

Generate SDKs in Kotlin

You can now specify kotlin as a supported language when using the -l, --language option with Postman SDK commands. This enables you to generate Kotlin SDKs, and use them across supported workflows like fetching builds and connecting to GitHub.

To learn more, see SDK CLI commands.

Improvements

Specify folders using paths in collection runs

The -i option in the postman collection command now supports specifying folders with paths.

To learn more, see Collection commands.

Original source

What’s New

Generate CLIs from your Postman Collection or API specification

Available on Team and Enterprise plans

You can now generate a fully-functioning command-line interface (CLI) application based on your Postman collections or OpenAPI specifications. The Postman CLI has been enhanced with two main end-users in mind: Agents (LLMs) and humans.

To learn more, see Generate CLI from your collection or specification.

Specify input data for Postman Flows

You can now use the --scenario option with the postman flows trigger command to specify a named scenario from the flow definition to construct the input payload, headers, and query parameters.

To learn more, see Flows commands.

Original source

What’s New

Generate SDKs in PHP, Go, and C#

Introduced support for PHP, Go, and C# in the scope of SDK generation. Previously, the Postman CLI supported SDK generation in Python, Typescript, and Java. Now, you can use CLI to generate SDKs in six languages.

To learn more, see SDK CLI commands.

Validate collections in v3 format

The Postman CLI now supports the postman collection lint command to verify that a collection matches the v3 YAML format.

To learn more, see Collection commands.

Original source

Improvements

New options for postman flows run and postman flows trigger

New options for postman flows run and postman flows trigger

Available on Enterprise plans

Two new options are now available for the Postman CLI flows commands:

Use the -e, --environment option with postman flows run to pass a Postman environment file at runtime, allowing the runner to hydrate environment variable values when executing your flows locally.

Use the -r, --result option with postman flows trigger to display only the response body from a triggered cloud flow run.

To learn more, see Flows commands.

Bug Fixes

Fixed an issue that caused postman workspace push to fail when using API key authentication. The command could fail because the workspace context was lost during the login step.

Fixed an issue where API key login was skipped if the provided key had a falsy value. The Postman CLI now correctly handles all provided API key values.

Original source

What’s New

The Postman CLI now supports the

postman collection migrate

command to migrate collections from v2.1 to v3 format.

Improvements

Sync connected local specifications and collections to the cloud

The

postman workspace push

command now supports syncing connected local specifications and collections to your workspace in the Postman cloud.

Bug Fixes

Fixed issues

Fixed an issue that prevented local mock servers from starting when using

postman mock run

or

postman collection run --mock

Fixed an issue that caused the

--color off

option to not work with the

postman collection run

command.

Original source

What’s New

New Postman CLI commands for Flows

Available on Enterprise plans

You can now manage and monitor your flows directly from the Postman CLI with five new commands.

• Use postman flows list to view all flows available in your workspace.
• Use postman flows deploy to deploy a flow to the Postman cloud from the CLI.
• Use postman flows trigger to trigger execution of a deployed flow.
• Use postman flows list-runs to view the run history for a deployed flow. The command displays each run's timestamp, ID, duration, status, and flow name in a table. Use --workspace to specify your workspace (required), --flow to filter by a specific flow, and --range to set the time window for results (default: last 1 hour).
• Use postman flows get-run to inspect a specific run in detail. Use --logs to display the full event log, and --filter to narrow output by block ID.

To learn more, see Postman CLI command options.

Improvements

• Improved gRPC schema resolution
• Schema resolution for gRPC is now faster and more reliable.

Bug Fixes

• Fixed an issue where gRPC schemas could get stuck for up to 30 seconds on some servers.

Original source

What’s New

Support for Private API Monitoring with runners (Available on Enterprise plans)

With Private API Monitoring, the Postman CLI now supports monitoring your organization’s internal APIs behind a firewall or deployed in a restricted network. This means you can monitor internal APIs without exposing your endpoints to the public internet.

Use the postman runner start command to start a runner with your runner’s ID and key. Once running, the runner polls Postman for upcoming monitor runs. The collection and its tests run in your network and the results are sent back to the Postman cloud.

To learn more, see Monitor internal APIs with runners.

Support for running performance tests

The Postman CLI now supports configuring and running performance tests against collections in your team. Performance tests enable you to simulate real-world traffic to your APIs and automatically surface performance issues before changes reach production.

Use the postman performance run command to integrate performance tests into your CI/CD pipeline and ensure your APIs stay fast and reliable with every release. The Postman CLI sends the results to the Postman cloud to help you debug performance test results.

To learn more, see Run a performance test using the Postman CLI.

Support for mock servers

The Postman CLI now supports using a mock server to run against your collection’s tests. This helps you validate your tests against the mocked responses of external APIs used in your service, both locally and in CI environments. With the Postman CLI, you can integrate a mock server into your CI/CD pipeline with the --mocks option when you run a collection with postman collection run.

You can also use the postman mock run command in your CI/CD pipeline to start a mock server as a dependency for your application or test suite. The mock server runs on the specified port until you stop it. This is useful for simulating an API server for your service or external tests.

To learn more, see Postman CLI command options.

Support for generating SDKs from collections and API specifications

The Postman CLI now supports generating client SDKs directly from your Postman collections or API specifications (such as OpenAPI). Generate production-ready SDKs in TypeScript, Python, and Java, making it easy to provide consumers of your API with idiomatic client libraries.

Use the postman sdk generate command with a collection ID, specification ID, local file, or publicly accessible URL as input. You can generate SDKs for one language at a time, multiple languages, or all supported languages at once using the --all flag. Generated SDKs are written to a configurable output directory (default ./sdks) with a subdirectory per language.

postman sdk generate <collection-or-spec-id> --language typescript python --output-dir ./sdks

To customize SDK generation, use the postman sdk init command to create a .postman/config.json configuration file where you can set the SDK name, version, authentication behavior, retry policies, and per-language options.

Additional SDK management commands are available:

• postman sdk list — List previous SDK builds for a collection or specification.
• postman sdk fetch — Download SDKs from a previous build by its build ID.
• postman sdk connect — Connect a collection to a GitHub repository for automated SDK pull requests. Once connected, use the --pr flag with postman sdk generate to automatically create pull requests with updated SDKs.

Support for running flows locally with the Postman CLI (Available on Enterprise plans)

You can use the postman flows run command to run local flows without exposing private APIs and sensitive data to the Postman cloud. The postman flows run command has options to set input values, show run log information, and use values from a scenario.

To learn more, see Postman CLI command options.

Improvements

Support for multi-protocol collection runs

The postman collection run command now supports gRPC and GraphQL collection runs.

To learn more, see Postman CLI command options.

Original source

What's New

Support for running performance tests

Running performance tests using the Postman CLI is available as a beta feature.

The Postman CLI now supports configuring and running performance tests against collections in your team. Performance tests enable you to simulate real-world traffic to your APIs and automatically surface performance issues before changes reach production. With the Postman CLI, you can integrate performance tests into your CI/CD pipeline and ensure your APIs stay fast and reliable with every release. The Postman CLI sends the results to the Postman cloud to help you debug performance test results.

Original source

What's New

Syntax validation for API specifications

The postman spec lint command now includes dedicated syntax validation. Previously, specs with syntax errors would display a generic message like "Unable to lint. Please check your specification for errors." Now you see the exact syntax errors with file names, line numbers, and clear descriptions, making it much easier to fix issues in your OpenAPI specifications.

New "Issue Type" column in output

Validation results now include an "Issue Type" column that distinguishes between Syntax errors (structural/parsing issues) and Governance violations (rule-based issues). This helps you quickly identify and prioritize what to fix first.

The new column is added at the end of CSV, JSON, and table outputs to maintain backward compatibility with existing CI/CD pipelines.

Fixed collection push failing due to owner ID mismatch

Fixed an issue where postman workspace push would fail to update collections when the resource ID format didn't include the expected owner prefix.

Original source