{"notes":[{"version":"1.76.0","content":"## Postman CLI v1.76.0\n### Improvements\n#### Run collections against a mock with one flag\nThe `--mock` option is removed from the `postman collection run` command. Use `--use-mock` instead, and name the URL or variable to redirect. For example, replace `--mock ./postman/mocks/orders` with `--use-mock \"{{baseUrl}} mock:./postman/mocks/orders\"`. A mock started this way binds a free port on its own and the run redirects to it, so there’s no port to set. The `--port` option now applies only to `--simulation`.\n#### Pass inline variables to local mocks during a collection run\nLocal mocks that `--use-mock` starts receive the run’s `--env-var` and `--global-var` values, so the mock’s handlers resolve the same inline variables as the run. Environment and globals files, passed with `--environment` or `--globals`, don’t reach the mock.\n#### Reference Shared Vault secrets by key in dataset sources\nThe `postman dataset source add` and `postman dataset source update` commands accept two new forms of secret reference. Use `vault:<KEY>` to look a Shared Vault secret up by key, instead of naming its IDs, or `env:<NAME>` to read the `POSTMAN_VAULT_<NAME>` environment variable.\n#### Create secrets with reusable JSON output\nThe `postman secret create` command accepts the `--json` option. It prints each secret’s key, secret ID, and vault ID, using the same field names as `postman secret list --json`, so you can feed the output straight into a `vault:` reference. Secret values are never printed.\n#### Make a mock or simulation live in one step\nThe `postman mock generate` and `postman simulation create` commands accept the `--deploy` option. It uploads the mock or simulation to Postman Cloud and deploys it to a live mock server without prompts. Add `--json` to print the server details, such as the URL.\n#### Get live server details as JSON when you deploy a simulation\nThe `postman simulation deploy` command accepts the `--json` option. It prints the live server’s details, such as the URL and visibility. Passing `--json` also skips the prompts for the server’s name, slug, and visibility and takes the defaults, so the deploy can run unattended.\n#### Deploy simulations as private by default\nThe `postman simulation deploy` command deploys a new simulation as private, so callers must send a Postman API key. Pass `--public` to let anyone with the link reach the server. Previously a new simulation deployed as public.\n#### Save each local simulation in its own folder\nThe `postman simulation create` command saves a local simulation as `postman/simulations/<slug>/<slug>.sim.yaml`, matching the layout the Postman app writes. Previously it saved the file directly in `postman/simulations/`, and simulations created that way still run.\n#### Run a simulation proxy from a simulation file\nThe `postman simulation run --proxy` command takes the same `.sim.yaml` file as a plain run, instead of a separate `simulation.yaml` routing config. Declare each member’s origin in the `.sim.yaml` to say which hostnames it stands in for.\n#### Get a handoff document with each new simulation\nThe `postman simulation create` command writes a `<name>.context.md` file beside the simulation’s `.sim.yaml`. It’s a prefilled handoff document for whoever works on the simulation next, human or agent.\n#### Find the app URL of a collection, environment, or monitor\nThe `postman collection get`, `postman environment get`, and `postman monitor get` commands show the element’s URL in the Postman app. With `--json`, the URL is the `url` key.\n#### Update scripts that read monitorUrl\nThe `monitorUrl` key in `postman monitor get --json` is deprecated and now carries the same value as the new `url` key. Read `url` instead.\n#### Remove the max steps option from context graph questions\nThe `--max-steps` option is removed from the `postman context-graph ask` command. The service’s own limit on reasoning steps now always applies.\n#### Use the Swift nullableAsOptional setting\nThe `postman sdk generate` command accepts `nullableAsOptional` under `languageOptions.swift` in your SDK configuration. When `true`, a nullable schema generates as `T?` instead of the tri-state `Nullable<T>`, which can represent an explicit JSON null. Previously the Postman CLI rejected the setting as an unknown option.\n#### Create workspaces from a guest session\nThe `postman workspace create` command works in the guest session that `postman init` starts. Run `postman signup` to claim the account and keep the workspaces. Previously the command refused any guest session.\n#### See the API key notice only after a failed command\nThe Postman CLI prints a one-line note when a command authenticates with the `POSTMAN_API_KEY` environment variable instead of an existing `postman login` session. It appears only when a command fails, alerting you that the key may be the cause. Previously it appeared on every run.\n### Bug Fixes\n- Fixed an issue where the Postman CLI accepted TLS connections through revoked intermediate certificates. It no longer trusts the `emSign ECC Root CA - G3`, `emSign Root TLS CA - G3`, or `AAA Certificate Services` roots, so a connection whose chain depends on them now fails.\n- Fixed an issue where `postman update` reported a failed installation even though the update was installed.\n- Fixed an issue where `postman skills status`, `postman skills update`, and re-running `postman init` refused to run in any repository postman init had set up.\n- Fixed an issue where `postman dataset query --json` printed failures only to stderr, and not to stdout."},{"version":"1.75.0","content":"## Postman CLI v1.75.0\n\n### What’s New\n#### View a workspace’s activity feed\n\nThe `postman workspace activity` command shows who changed what in a workspace and when. It reads the workspace bound to the current folder or the workspace ID you pass. Filter the feed with `--type`, and add `--json` for machine-readable output.\n\n### Improvements\n#### Run application tests in a CI/CD pipeline\n\nThe `postman app test` command doesn’t prompt for setup when there’s no interactive terminal, such as in a CI job. It uses the options you pass instead. When a collection or a test command is missing, the command exits with code `2` and names the options to pass.\n\n#### Generate a collection from test traffic when you run application tests\n\nThe `postman app test` command accepts the `--generate-collection` option. It captures traffic from your application tests and generates a collection with a test for each captured API endpoint. The tests assert the status codes and response times observed during the capture, and the shape of each JSON response body. It then runs those tests.\n\n#### Set up the collection and capture plugin in one step\n\nThe `postman app test` command accepts the `--yes` option. It generates a collection from test traffic and installs the capture plugin, each only when it isn’t already set up. Passing `--generate-collection` requests the same collection generation on its own.\n\n#### Use your Playwright configuration without setting a test command\n\nWhen you don’t pass the `--command` option, the `postman app test` command runs `npx playwright test` if it finds a Playwright configuration file. Previously you had to pass that command yourself.\n\n#### Set up application test capture without prompts\n\nThe `postman app setup-capture` command accepts the `--yes` option to install the `postman-playwright` capture plugin and patch your Playwright configuration file without asking for confirmation. Outside an interactive terminal, the command makes no changes and exits with code `2` unless you pass `--yes`.\n\n#### Preview capture setup before it changes files\n\nThe `postman app setup-capture` command accepts the `--dry-run` option. It shows the current capture setup and lists what the command would install or patch, and it changes no files.\n\n#### Get an error exit code when capture setup finds no Playwright configuration\n\nThe `postman app setup-capture` command exits with code `1` when it finds no Playwright configuration file, with or without the `--config` option.\n\n#### Use YAML manifests for mocks and simulations\n\nThe `postman mock` and `postman simulation` commands accept only YAML mock manifests. A `.json` manifest fails with “JSON mock manifests are not supported.” Convert it to `.yaml`. Previously both formats worked.\n\n#### Pass --verbose to keep request detail in mock and simulation logs\n\nThe `postman mock run` and `postman simulation run` commands print one line for each request, plus any applied scenario or error. Pass `--verbose` to also print request and response headers and bodies. Previously every request printed that detail.\n\n#### Pass --verbose to keep headers and bodies in ndjson request events\n\nWith `--output ndjson`, each `request` event from the `postman mock run` and `postman simulation run` commands carries the status code, duration, and any scenario or error. Pass `--verbose` to also include request and response headers and bodies. Previously every event included them.\n\n#### Read more detail in ndjson request events\n\nWith `--output ndjson`, the `request` events from the `postman mock run` and `postman simulation run` commands add the `responseSize`, `scenarios`, and `error` fields.\n\n#### Get a readable default slug when you deploy a mock or simulation\n\nThe `postman mock deploy` and `postman simulation deploy` commands build the default `--slug` from the mock’s name, such as `orders-3f9c1a`. A mock or simulation with no name gets `new-mock-` and six hexadecimal characters. Previously a nameless mock or simulation got a slug built from its ID.\n\n#### List runners and regions in a guest session\n\nThe `postman runner list` and `postman runner regions` commands work in a guest session, which the `postman init` command creates. Previously, the commands stopped with an \"Authentication required\" error.\n\n### Bug Fixes\n\n- Fixed the `postman collection publish` command returning a documentation URL on an internal host that only resolves inside Postman’s network. The command returns the URL on `documenter.getpostman.com`.\n- Fixed the `postman performance run` command using excessive memory when requests with large bodies fail.\n- Fixed the `postman app test` command logging an incorrect outcome message after remote result ingestion.\n"},{"version":"1.74.0","content":"## Postman CLI v1.74.0\n\n### What’s New\n#### Delete a flow\n\nThe `postman flows delete` command deletes a flow in the Postman Cloud by its flow ID or a local flow by its file path. The command asks for confirmation unless you pass `--yes`.\n\n### Improvements\n#### Lint a specification against a local Spectral ruleset\nThe `postman spec lint` command accepts the `--ruleset` option, so you can lint an OpenAPI or AsyncAPI specification against a Spectral ruleset on your machine. Custom functions are supported. The same sign-in and plan requirements apply as for linting with governance rules.\n\n#### Generate mocks that keep state\n\nThe `postman mock generate` command accepts the `--stateful` option. For endpoints that map to create, read, list, update, and delete operations, the command generates handlers that store data with `pm.state` instead of returning static example responses.\n\n#### Run performance tests in local mode\n\nThe `postman performance run` command now supports local mode, so you can pass the path to a local collection instead of a cloud collection ID. Whether the run is recorded in Postman depends on whether that collection is linked to a cloud collection in `.postman/resources.yaml`.\n\n#### Use a Native Git-linked local collection with cloud runners\n\nThe `postman performance run` command accepts the path to a Native Git-linked local collection with the `--runner postman-cloud` and `--runner postman-cloud-static-ip` options.\n\n#### Check whether a performance run was recorded in ndjson output\n\nWith `--output ndjson`, the `postman performance run` command adds a `recorded` field to the `summary` event, so you can tell whether a run was recorded in Postman.\n\n#### Show the sign-in notice only when a performance run needs it\n\nPreviously, the `postman performance run` command prompted a logged-out user to sign in even when the run didn’t need a Postman account. The command now prints that notice only when part of the run reaches Postman Cloud.\n\n#### Push local work automatically when you sign up as a guest\n\nPreviously, if you had local work that wasn’t pushed yet, the `postman signup` command warned you to run `postman workspace push` yourself. The command now pushes new work under `postman/` to your guest workspace for you, so the workspace you keep isn’t empty.\n\n#### Skip the push when you sign up\n\nThe `postman signup` command accepts the `--no-push` option to skip pushing local work to your guest workspace.\n\n#### Protect headers and descriptions when syncing a collection\n\nThe `postman spec sync collection` command stops with exit code `8` and writes nothing when a local sync would remove headers or descriptions that the specification doesn’t generate, as it already did for scripts. Pass `--force` to overwrite anyway.\n\n#### Preview a collection sync without writing files\n\nThe `postman spec sync collection` command accepts the `--dry-run` option, which lists the files a sync would write, marks any content the specification doesn’t generate, and writes nothing.\n\n#### Write only changed files when syncing a collection\n\nThe `postman spec sync collection` command writes only the collection files that don’t already match the specification.\n\n#### Save an HTML report for a flow run with a dataset\n\nThe `postman flows run` command accepts `--reporters html` for dataset runs, saving a report with the results for each row of the dataset view.\n\n#### End the install script when the installed binary doesn’t run\n\nThe install script for macOS and Linux ends with an error when the installed `postman` binary doesn’t print a version.\n\n### Bug Fixes\n\n- Fixed the install script for macOS and Linux writing through an existing `bin/postman` symlink, which left `$HOME/.local/bin/postman` as a symlink to itself.\n- Fixed the `postman performance run` command with the cloud runners dropping the `--pass-if` verdict when only the teardown collection failed the run.\n- Fixed the `postman signup` command reporting unpushed guest work for a fresh guest whose only local files were installed skills.\n- Fixed the Claude Code plugin hint printing when you pass `--json` or `--output`, or when stdout or stderr isn’t a terminal.\n"},{"version":"1.73.0","content":"## Postman CLI v1.73.0\n\n### Improvements\n#### Lint a specification’s syntax without governance checks\n\nThe `postman spec lint` command accepts the `--issueType` option with the value `syntax`. The option limits linting to syntax checks and skips governance rules, and it works on a local specification file even when you aren’t signed in.\n\n#### Linting a local specification requires signing in\n\nWhen you aren’t signed in, the `postman spec lint` command stops with an error for a local specification file. The error tells you to run `postman login`, or to use `--issueType=syntax` to lint syntax only. Previously, the command ran the syntax checks and showed a sign-in notice instead.\n\n#### Install the Postman CLI to a standard `PATH` location in CI\n\nThe install script for macOS and Linux installs the `postman` binary to `/usr/local/bin` when that location is writable without sudo. Otherwise, it installs to `$HOME/.local/bin` as before, and it never prompts for sudo unless you pass `--system`. Because `/usr/local/bin` is on the default `PATH` of most systems, the `postman` binary is found in later CI steps and Docker `RUN` lines.\n\n#### Find the Postman CLI at a fixed path\n\nAfter the install script runs, the Postman CLI is always reachable at `$HOME/.local/bin/postman`. This is because when the script installs the binary to another location, it adds a symlink at `$HOME/.local/bin/postman` pointing to the binary. This gives callers such as the Postman desktop app one fixed path to check.\n"},{"version":"1.71.0","content":"## Postman CLI v1.71.0\n\n### What’s New\n#### List the secrets in a workspace’s Shared Vault\n\nThe `postman secret list` command lists the secrets in a workspace’s Postman Shared Vault. It shows each secret’s key, secret ID, vault ID, and allowed domains, and never shows the secret’s value. Pass the secret ID and vault ID to `postman environment var set` to link an environment variable to a secret.\n\n#### Delete a collection\n\nThe `postman collection delete` command deletes a collection by its collection ID or a local collection by its directory path. The command asks for confirmation unless you pass `--yes`.\n\n#### Delete an environment\n\nThe `postman environment delete` command deletes an environment by its environment ID or local environment file path. The command asks for confirmation unless you pass `--yes`.\n\n#### View a workspace dependency\n\nThe `postman dependency get` command shows a workspace dependency declared in `.postman/resources.yaml`. Use `--type` to match only collection, environment, or mock dependencies.\n\n#### Get a performance run by its run ID\n\nThe `postman performance get` command shows one performance run by its run ID. Use `--output` to choose the format. It accepts `table`, which is the default, or `json`. The `--json` option is an alias for `--output json`.\n\n#### Read and update global variables\n\nThe `postman globals get` command reads local workspace globals, or the globals of a workspace in the Postman Cloud when you pass `--workspace`. The `postman globals var get`, `postman globals var set`, and `postman globals var unset` commands read, set, and remove one global variable.\n\n### Improvements\n#### Serve simulation mocks behind a local proxy\n\nThe `postman simulation run` command accepts the `--proxy` option to serve the mocks behind a local HTTP(S) forward proxy instead of one routed port. Point `HTTP_PROXY` and `HTTPS_PROXY` at the proxy to reach each mock by hostname without code changes. Use `--proxy-port` to set the proxy port.\n\n#### Redact credentials in simulation request logs\n\nThe request log lines that the `postman simulation run` command prints redact query string values with credential-like names, such as `token` or `api_key`.\n\n#### Enter secret values in a browser form\n\nThe `postman secret create` command opens a one-time browser form on your machine to enter the secret value. The command prints only the secret names and IDs, so an AI agent that runs the command only sees names and IDs. Use `--terminal` to enter the value in the terminal instead. The `--value-stdin` option reads the value from stdin and implies `--terminal`. Use `--timeout` to set how many seconds the command waits for the form.\n\n#### Create several secrets in one command\n\nThe `postman secret create` command accepts several secret names when you use the browser form. The form shows one field for each name.\n\n#### Choose the output format for performance runs\n\nThe `postman performance list` command accepts the `--output` option with the value `table` or `json`. The `--json` option is an alias for `--output json`.\n\n#### Retry on server errors when syncing a workspace\n\nThe `postman workspace push` and `postman workspace pull` commands retry requests that fail with a server error, using increasing delays and up to two retries. After repeated failures, the command stops the operation instead of retrying.\n\n#### Send private runner events through your proxy\n\nThe `postman runner start` command sends its usage events through the proxy that you set with `--proxy` or `--egress-proxy`.\n\n### Bug Fixes\n\nFixed the `postman dataset source add` help text implying that every database source needs a table. Without `--table`, the source connects to the whole database.\n"},{"version":"1.70.0","content":"## Postman CLI v1.70.0\n\n### What’s New\n#### Create, run, and manage simulations with a new command\n\nThe `postman simulation` command replaces the `postman simulate` command. Use the new command family to create, list, get, run, push, deploy, and delete simulations. The `postman simulation run` command serves all the mocks on one port. The now deprecated `postman simulate run` command used to open a port for each mock.\n\n### Improvements\n#### Install Postman CLI without sudo\n\nThe install script for macOS and Linux installs to `$HOME/.local/bin` by default and doesn’t prompt for `sudo`. Use `--prefix` to choose another location or `--system` to install system-wide. Previously, the script installed to `/usr/local` and used `sudo` when that location wasn’t writable.\n\n#### Run `postman init` without prompts\n\nThe `postman init` command accepts the `--yes` option to take the default for every question instead of asking or stopping. The command also creates and binds a workspace with `personal` visibility unless you set another value with the `--visibility` option. When used in CI, the command doesn’t create a workspace.\n\n#### Use guest sessions with specification commands\n\nThe `postman spec list`, `get`, `create`, and `delete` commands and the `postman spec file` commands accept the guest session that the `postman init` command creates.\n\n#### Use guest sessions with environment commands\n\nThe `postman environment new`, `list`, `get`, and `var set` commands accept a guest session when you use them with an environment in a Postman Cloud workspace.\n\n#### List local mocks by default\n\nThe `postman mock list` command now lists the file-backed mocks in your repository by default. To list the same mocks as seen from your cloud workspace, including their deployment status and public URL, pass the `--workspace <id>` option. Previously, the command listed cloud workspace mocks by default.\n\n#### Shape load test profiles with segments\n\nThe `postman performance run` command has new options for shaping the load profile. Use `--load-segments` to set how long each phase lasts, as a comma-separated list in order, such as `--load-segments 1m30s,20s,40s`. The `ramp-up` profile takes 2 values, `spike` takes 3, and `peak` takes 4. Use `--base-vu` to set the virtual users the run starts from and `--peak-vu` to set the peak. Run `postman performance run --help` to understand more about each profile.\n\n#### Pull flows into your local workspace folder\n\nThe `postman workspace pull` command now includes flows in what it pulls from a workspace in the Postman Cloud. The Postman CLI rewrites each flow’s references to environments, saved requests, and sub-flows so they resolve against local files, making a pulled flow usable as-is.\n\n#### Pass several conditions with `--pass-if`\n\nThe `postman performance run` command accepts multiple `--pass-if` options. The run passes only if every condition passes. Previously, a second `--pass-if` condition replaced the first.\n\n#### See how many matched requests have assertions\n\nThe `postman application test` command shows how many matched requests have assertions and how many don’t, such as `5 matched (3 with tests, 2 without)`. The breakdown appears only when at least one matched request has no assertions. Previously, the output showed only the matched and not matched counts.\n\n### Bug Fixes\n\n- Fixed the `postman collection run` command not resolving Postman Shared Vault secrets linked to collection variables.\n- Fixed the `postman flows run` command failing to load a flow’s sub-flows when the flow sits inside a Postman workspace.\n- Fixed the `postman application test --capture-only` command failing or returning empty results on every run after the first. The command replaces the contents of the output directory on each run.\n- Fixed the `postman performance run` command misreading a `--duration` value that includes a unit. The command ignored the unit and read only the number as minutes, so `30s` ran for 30 minutes and `1h` ran for 1 minute. The `--duration` option accepts only a whole number of minutes, such as `--duration 30`, and the command returns an error for any other value.\n- Fixed the `postman performance run` command accepting `--vu-count` values that aren’t whole numbers. The command refuses them with an error.\n"},{"version":"1.69.0","content":"## Postman CLI v1.69.0\n\n### What’s New\n#### Read requests and folders in a collection without exporting it\n\nThe `postman collection request get` and `postman collection folder get` commands print a single request or folder from a collection, either locally or from the cloud. You can inspect an item before changing it instead of reading collection files by hand.\n\n#### View a single specification file\n\nThe `postman spec file get` command prints the contents of one file from a specification without reading the whole specification. This helps you review contract details from the terminal.\n\n#### Create a secret in your team’s Shared Vault\n\nThe `postman secret create` command adds a secret to your team’s Postman Shared Vault. This streamlines secure credential management as part of your automation and CI workflows.\n\n#### Create and manage examples under a request\n\nThe `postman collection example` command family lets you add, update, get, list, and remove examples (saved responses) under a request. It works on local v3 collections or cloud collections.\n\n### Improvements\n#### Schema-valid values when generating collections from OpenAPI\n\nCollections generated from an OpenAPI specification with the `postman spec generate collection` command produce repeatable values that respect schema constraints such as `minimum`, `maximum`, and `enum`. Example values were previously randomized on every run, which caused unnecessary file diffs and unreliable mock responses. Regenerating the same specification produces identical files, so drift checks and code reviews stay reliable.\n\n#### Preserve custom scripts when syncing a specification\n\nThe `postman spec sync collection` command preserves your custom pre-request and post-response scripts, instead of silently overwriting them as before. A sync that would discard a changed script stops and lists the affected files.\n\n### Bug Fixes\n\nFixed an issue where certain CLI commands reported a false network error instead of the actual failure reason, which made problems harder to diagnose.\n"},{"version":"1.68.0","content":"## Postman CLI v1.68.0\n\n### What’s New\n#### Run a subset of requests in a monitor\n\nYou can configure a monitor to run a subset of its collection’s requests instead of the full collection. Pass `-i, --item <id>` (repeatable) to `postman monitor create` or `postman monitor update` to list the requests or folders to include, in the order you want them to run. On `postman monitor update`, `--clear-items` resets the selection so the monitor runs every request again.\n\n#### Import a collection from a curl command or HAR file\n\nThe new `postman collection import <src>` command creates a Postman Collection from a curl command or a HAR file.\n\n### Improvements\n#### View a scenario’s endpoints for a mock\n\nThe `postman mock get` command now lists the endpoints for every scenario associated with a mock, not only the default one. This enables you to discover and use non-default scenario endpoints without leaving the CLI.\n\n#### SSL options and a cookie jar for a request\n\nThe `postman request` command now accepts SSL configuration and cookie jar options. This gives you more control over request behavior when working with secured endpoints or session-based APIs.\n\n#### Lint warning for request file names\n\nThe `postman collection lint` command warns when a `.yaml` or `.yml` request file in a collection folder doesn’t use the required `.request.yaml` suffix. This helps you catch misnamed request files before you run the collection.\n\n#### JSON output for more workspace commands\n\nThe `--json` option is now supported on `postman workspace push`, `pull`, `create`, `prepare`, `connect-git`, and `disconnect-git`. Each command prints a structured result object, making workspace output easier to consume in scripts and CI/CD pipelines.\n\n### Bug Fixes\n\n- Fixed an issue where `postman dataset query` exited with code 0 and produced no output when an underlying component couldn’t start. The command now surfaces the failure.\n- Fixed an issue where `postman workspace list` didn’t carry the pagination cursor, which could return incomplete results in non-interactive environments.\n"},{"version":"1.67.0","content":"## Postman CLI v1.67.0\n\n### What’s New\n#### Publish collection documentation to the cloud\n\nThe `postman collection publish` command publishes a cloud collection’s public documentation, making it visible to anyone, or requests Community Manager approval when your workspace requires it. Configure the publish with `--environment`, `--title`, `--description`, and `--note`, and add `--json` for machine-readable output.\n\n### Improvements\n#### See full request and response details while a mock runs\n\nThe `postman mock run` command now streams the same detailed request and response log as `postman mock log`, with secrets redacted. Pass `--output ndjson` for a machine-readable event stream instead.\n\n#### Every worksheet in a spreadsheet becomes its own dataset source\n\nThe `postman dataset source add` command now adds every worksheet in a spreadsheet (`xlsx`, `xls`, `ods`) as its own queryable datasource, named `source_<worksheet>`.\n\n#### Keep a request’s URL and query parameters in sync\n\nThe `postman collection request update` command now updates a request’s stored query parameters to match whenever you pass the `--url` option with a new query string. The `postman collection lint` command now flags a request whose query parameters and URL don’t match.\n\n#### Installers add Postman CLI awareness for coding agents\n\nThe Postman CLI’s install scripts now add a short note to your Claude Code or Codex configuration, if you already use one, so a coding agent on the machine knows the CLI is available. The update preserves any existing instructions and never fails the install.\n\n### Bug Fixes\n\n- Fixed the `postman workspace list` command silently ignoring the `--type` option, returning every workspace.\n- Fixed the `postman request` and `postman collection run` commands resolving a blank YAML environment value to the literal string `null` instead of an empty string.\n- Fixed the `postman collection run --iteration-data-dataset` command printing a misleading \"No authorization data found\" message for local file-backed datasets, even though the run completed successfully.\n- Fixed the `postman workspace push` command to handle Postman collections in the legacy JSON format.\n"},{"version":"1.66.0","content":"## Postman CLI v1.66.0\n\n### What’s New\n#### Delete a specification\n\nThe `postman spec delete` command removes a specification by its cloud ID or local file path. Pass `-y` or `--yes` to skip the confirmation prompt, and `--api-key` to authenticate when you delete by cloud ID. Deleting a specification can’t be undone.\n\n#### Remove a workspace dependency\n\nThe `postman dependency remove` command removes a workspace dependency and deletes its local files. Identify the dependency by its cloud ID, display name, or on-disk name from the `postman dependency list` command. Removing a collection also removes the environments pinned to it, unless another collection pins them too.\n\n### Improvements\n#### Protect an existing collection from being overwritten\n\nThe `postman spec generate collection` command no longer overwrites an existing local collection, so it can’t erase the test scripts you added to it. To regenerate and replace that collection on purpose, pass `--force`.\n\n#### Use datasets in a mock’s request handlers\n\nThe `postman mock run` command accepts a `--dataset` option that loads one or more local `.dataset.yaml` files, or directories of them. The mock’s request handlers can then read them with `pm.datasets(<id>)`. Pass `--dataset` more than once to load several.\n\n### Bug Fixes\n\n- Fixed the `postman request` command so a response with a non-2xx or non-3xx status code exits with code `1`.\n- Fixed `postman collection list` so it defaults to your local project’s collections when you don’t pass `--workspace`. Previously it errored when no cloud workspace was configured.\n- Fixed the `-o, --output` option on the `postman request` command so it saves the complete response to the JSON file you name.\n"},{"version":"1.65.0","content":"## Postman CLI v1.65.0\n\n### What’s New\n#### Delete a workspace from the CLI\n\nThe `postman workspace delete <workspaceId>` command permanently deletes a workspace and everything in it.\n\n#### Disconnect a workspace from Git\n\nThe `postman workspace disconnect-git [workspaceId]` command removes the Git integration from a workspace without leaving the CLI. It disconnects the workspace in Postman and clears the connection in `.postman/resources.yaml`. No local files are deleted. With no ID, it disconnects the workspace this folder’s connected to. Pass `--yes` to skip the confirmation prompt in CI.\n\n#### Two-way sync between specifications and collections\n\nYou can now keep a specification and its generated collection linked and regenerate either side on demand. The `postman spec generate collection <spec>` command creates a collection from a specification and records the link. The `postman spec sync collection <spec>` command regenerates the collection from its linked specification. In the other direction, `postman collection generate spec <collection>` creates an OpenAPI specification from a collection, and `postman collection sync spec <collection>` regenerates the specification from its linked collection. Both directions work in local and cloud modes.\n\n### Improvements\n#### Mock run history is recorded\n\nThe `postman mock run` command records a durable start history for eligible runs, so CLI and CI runs appear under **Previous starts** in Postman alongside runs started from the desktop app. Runs started from a Postman Cloud ID record automatically. For a run started from a local path, pass `--workspace <id>` to record its history. Use `--no-history` to opt out. Recording is best-effort and never blocks the mock server.\n\n#### Setup and teardown lifecycle collections for local performance runs\n\nThe `--setup-collection` and `--teardown-collection` options on `postman performance run` now work with `--runner local`, not only the Postman Cloud runners. Use them to prepare test data before a run and clean up state after it.\n\n### Bug Fixes\n\n- Fixed an issue where `postman workspace diff` didn’t show newly created mocks before their first push. Mocks that exist locally but aren’t yet in the Postman Cloud now appear in the diff as pending creation.\n- Fixed an issue where `postman workspace push` renamed a specification to `index.yaml` in the cloud, ignoring the name given to `postman spec create -n`. The user-specified name is now preserved.\n- Fixed an issue where mock response bodies contained unresolved type placeholders.\n"},{"version":"1.64.0","content":"## Postman CLI v1.64.0\n\n### What’s New\n#### Manage collection folders and requests in a guest session\n\nGuest users can add, update, and remove folders and requests in a collection with the Postman CLI. These operations previously required full authentication credentials. They are available to users operating under a guest session.\n"},{"version":"1.63.0","content":"## Postman CLI v1.63.0\n\n### What’s New\n#### Add, update, and remove collection folders\n\nThe `postman collection folder add`, `postman collection folder update`, and `postman collection folder rm` commands manage folders inside a collection, both locally and in the Postman Cloud. Pass the collection with `--collection <id|name>` and scope to a subfolder with `--folder`. The `add` command creates an empty folder. The `update` command changes a folder’s name, description, auth, or scripts. The `rm` command removes a folder. Add `--workspace` to edit a cloud collection, or work against local git-native files by default. All three support `--json`.\n\n### Improvements\n#### Run collection commands in a guest session\n\nThe `postman collection list` and `postman collection get` commands run in a guest session.\n\n### Bug Fixes\n\n- Fixed the `postman init --json` command exiting with a success code when the requested workspace was not created. It now exits non-zero and runs the workspace step when `--visibility` asks for one.\n- Fixed the missing interactive header and preflight error output on `postman performance run`. The `Live view` link and the `--data-file` validation error are restored on the default `--output auto` path.\n- Fixed `postman spec create --spec-version` rejecting full versions such as `3.0.3`. Patch versions are accepted for OpenAPI and AsyncAPI, and Swagger 2.0 reports a clear message because it defines only `2.0`.\n- Fixed `postman spec generate collection` output so type placeholders resolve to typed default values, headers and parameters use the array shape the v2.1 collection format requires, and example names are sanitized.\n- Fixed `postman workspace lint` reporting a governance API error as a per-specification warning on plans that do not include API Governance. The command now skips governance on those plans.\n- Fixed the error a guest session receives when creating a workspace. The `postman workspace create` command explains that workspace creation requires an account and points to `postman signup`.\n- Fixed `postman collection request update --param` so query parameters are written in the v3 `queryParams` shape and the request URL query string stays in sync.\n- Fixed `postman init` refusing to run on a `postman/mocks/<name>/` directory that the CLI generated itself.\n"},{"version":"1.62.0","content":"## Postman CLI v1.62.0\n\n### What’s New\n#### Add, update, and remove a collection’s requests\n\nThe new `postman collection request` commands let you add, update, and delete the requests in a local v3 collection. Pass `--workspace` to work on a collection in the Postman Cloud instead.\n\n#### List the teams in your organization\n\nThe new `postman team list` command lists the teams inside your organization. For example, you can use it to find a team’s ID for a command like `postman workspace create`.\n\n#### Send feedback about the Postman CLI\n\nThe new `postman feedback` command lets you, or an agent, submit feedback about CLI usability, gaps, and suggestions.\n\n#### `postman context` is now `postman describe`\n**Available as a beta feature**\n\nThe `postman context` command has been renamed to `postman describe`. The command does the same thing as before, fetching API context for AI coding agents. The rename is designed to avoid potential human and agent confusion with the unrelated `postman context-graph` command. Please update any scripts or automation that call `postman context` to use `postman describe` instead.\n\n### Improvements\n#### See a new project’s layout as a file tree\n\nThe `postman init` command now prints the files it generates as a file tree. This means you can see the project’s shape at a glance instead of a flat list of paths. Machine-readable output (`--json`) is unchanged.\n\n#### Clearer reminder when you’re working as a guest\n\nWhen you’re in a guest session, the Postman CLI now ends most commands with a reminder that your guest work may be lost unless you claim it. It points you to run `postman signup` to keep your work.\n\n#### Stream live performance results for non-interactive runs\n\nThe `postman performance run` command now accepts `--output ndjson`, which streams live results as newline-delimited JSON. This can be useful when you pipe the output or run the command from an agent or CI.\n\n#### Use Postman Cloud collection and monitor commands as a guest\n\nThe Postman Cloud `postman collection` and `postman monitor` commands now accept the guest session that `postman init` creates. This lets you use the commands without signing in first.\n\n### Bug Fixes\n\nFixed the `postman workspace create` command so it works for team users. Creating a team-visibility workspace previously failed on organization-enabled teams and when using an API key.\n"},{"version":"1.60.0","content":"## Postman CLI v1.60.0\n\n### What’s New\n#### Ask natural-language questions about your team’s APIs\n\nThe `postman context-graph ask` and `status` commands let you ask natural-language questions about the APIs and dependencies indexed in your team’s Context Graph. Run `ask` with `--wait` to get the answer inline, or without it to get an ID you check later with `status`. For example, `postman context-graph ask \"What depends on billing-api?\" --wait` submits a question, and `postman context-graph status <id>` checks on a question you asked earlier. Add `--json` to either command for machine-readable output.\n\n#### Change or remove a monitor’s environment\n\nThe `postman monitor update` command accepts `-e, --environment <id>` to set or replace the environment a monitor runs its collection with. You can use `--clear-environment` to run it with no environment. Previously, you could choose the environment only when creating the monitor.\n\n#### Get details for a single workspace\n\nThe new `postman workspace get` command fetches one workspace by ID and prints its details, such as its visibility, the team that owns it, and its timestamps. It’s read-only, so it’s a safe way to inspect workspace metadata in scripts and automation.\n\n#### List a collection’s past performance runs\n\nThe new `postman performance list` command lists a collection’s past performance test runs, newest first, so you can review history and track trends. Specify the collection with its ID.\n\n#### Create and manage JDBC dataset sources\n\nThe `postman dataset` commands can now create and manage JDBC dataset sources without leaving the CLI. You can create a dataset with a JDBC source, attach or update a JDBC source on an existing dataset, and inspect a driver’s metadata with `postman dataset jdbc inspect` before you configure it.\n\n#### Use JDBC dataset views on your self-hosted runners\n\nMonitors that run on your self-hosted Private API Monitoring runners can now use a JDBC dataset view as iteration data. The runner resolves the view against its JDBC source and passes the resulting rows to the run. To enable this, start the runner with the new `--dataset-jdbc-driver-dir` option on `postman runner start`, pointing it at a folder of JDBC driver files.\n\n### Improvements\n#### Check for CLI updates without installing them\n\nRun `postman update --check` to see whether a newer Postman CLI is available, without installing it. If an update exists, the command points you to `postman update`. Otherwise, it confirms you’re on the latest version.\n\n#### Create a guest session without signing up\n\nThe `postman signup` command now accepts a `--guest` option that creates the same kind of anonymous guest session as `postman init`, and exits without signing up. You can claim the guest session later by running `postman signup`.\n\n#### Consistent terminology and output across monitor and runner commands\n\nThe `postman monitor` and `postman runner` commands now share one vocabulary and one table style, so their output reads consistently from one command to the next.\n\n#### Clearer lint failures when you push a workspace\n\nWhen `postman workspace push` fails a lint check, it now reports the problem more clearly. It shows the blocking issues alongside the rejected items, and only suggests `postman workspace lint --fix` when the issues are fixable automatically.\n\n### Bug Fixes\n\n- Fixed an issue where the `postman whoami` command could truncate the CLI’s configuration file when it ran alongside other commands. The CLI now writes that file atomically.\n- Fixed `postman logout`so it properly ends a guest session and no longer surfaces a 503 error.\n"},{"version":"1.59.0","content":"## Postman CLI v1.59.0\n\n### What’s New\n#### See per-request latency history for a monitor\n\nThe new `postman monitor metrics` command shows a monitor’s per-request latency and outcomes, grouped by request and region. Use it to see which request is slow or failing and how its behavior has trended over time.\n\n#### Preview local workspace changes before pushing\n\nThe new `postman workspace diff` command shows the differences between your local workspace and your Postman Cloud workspace, so you can preview what a `postman workspace push` would change. Use this read-only command to review drift before you push.\n\n#### Generate a collection from a specification\n\nThe new `postman spec generate collection` command creates a Postman collection from an OpenAPI specification. Use `--folder-strategy` to group endpoints into folders by `Paths` (default) or `Tags`. Pass a local file path to generate the collection on disk, or a cloud spec ID to generate it in the Postman Cloud.\n\n#### Scaffold collections and environments\n\nThe new `postman collection new` and `postman environment new` commands create an empty collection or environment locally. You can pass `--workspace` to create the element in a Postman Cloud workspace instead.\n\n#### Get and list collections\n\nThe new `postman collection get` command fetches a collection and prints it to the terminal in v3 format, without saving it anywhere. The new `postman collection list` command lists your collections. By default, it lists your local project’s collections, but you can pass `--workspace` to list a specific Postman Cloud workspace’s collections instead.\n\n#### Update the Postman CLI\n\nThe new `postman update` command updates the Postman CLI to the latest version using the method you originally installed it with.\n\n### Improvements\n#### List runners by workspace\n\nThe `postman runner list` command now accepts `--workspace` to show only the runners in a specific workspace.\n\n#### Stay signed in after signing up\n\nWhen you complete sign-up, the Postman CLI now signs you in automatically, so you don’t have to authenticate again. This includes when you open a sign-up link from an agent.\n\n### Bug Fixes\n\n- Fixed an issue where end-to-end collection runs counted skipped requests as errors.\n- Fixed an issue where `postman app test` could match the wrong request when traffic hit the same path on a different port or environment. It now also compares the host and port whenever both the captured and expected requests resolve to a concrete host.\n"},{"version":"1.58.0","content":"## Postman CLI v1.58.0\n\n### What’s New\n#### Create, schedule, and manage monitors\n\nNew `postman monitor` and `postman runner` commands let you manage monitors from the command line, not just run them. Create a collection-based monitor with a cron schedule and time zone, choose where it runs, and set failure notifications, retries, and run options. Update, pause, resume, delete, list, and get monitors, and inspect a monitor’s jobs and runs. The `postman monitor run` command gains `--async`, which returns the run’s job ID and Postman URL without waiting for the run to finish. The `postman runner list` and `regions` commands show your self-hosted runners and the valid region and runner values.\n\n#### List, install, and update dependencies\n\nNew `postman dependency list`, `install`, and `update` commands inspect and materialize your project’s declared dependencies: `list` shows the dependencies in `.postman/resources.yaml`, `install` materializes them into `postman/.dependencies/`, and `update` refreshes them to the latest content.\n\n#### Create and edit API specifications\n\nNew `postman spec` commands let you author API specifications from the command line. The `postman spec create` command creates a specification. Without a path, it creates one in your Postman workspace. With a path, it scaffolds a minimal file locally, with no sign-in required. It supports OpenAPI, AsyncAPI, GraphQL, protobuf, and Smithy formats. Once a specification exists, use the new `postman spec file` commands (`add`, `update`, and `rm`) to add, change, and remove its individual files, either by ID in your workspace or by local directory path.\n\n#### Push mocks to the Postman Cloud and run collections against them\n\nThe new `postman mock push` command uploads a mock from your repository to the Postman Cloud. The first push creates it in the cloud, and each later push updates that same mock instead of creating a duplicate, so your repository stays the source of truth. The `postman collection run --mock` command now accepts a cloud mock by ID, not just a local path, so you can run a collection against a mock you’ve pushed.\n\n#### Identify the current session with `whoami`\n\nThe new `postman whoami` command shows the Postman account or guest session the CLI is currently using. This enables you to verify your session in automated and local workflows.\n\n### Improvements\n#### Automatically resolve secrets in environment commands\n\nThe `postman environment` commands now resolve secret values referenced in your variables when the `--show-secrets` parameter is passed.\n\n#### See why a workspace command failed\n\nWhen a `postman workspace` command fails, the CLI now reports the specific reason instead of a generic error, so you can see exactly what went wrong.\n"},{"version":"1.57.0","content":"## Postman CLI v1.57.0\n\n### What’s New\n#### Manage environments\n\nNew `postman environment` commands let you work with Postman environments from the command line: list environments, read an environment, and set, read, or remove individual variables. The commands work with local environment files and cloud environments referenced by ID. Add `--json` for machine-readable output.\n\n#### List your API specifications\n\nThe `postman spec list` command lists API specifications. Pass a path to scan local specification files (OpenAPI or AsyncAPI) on disk, or run it without a path to list the specifications in your Postman workspace. The output includes specification names, IDs, types, and root files. Add `--json` for machine-readable output.\n\n#### Get a full API specification\n\nThe `postman spec get <spec>` command reads a specification’s full definition by ID or local file path, including every file in a multi-file specification. It prints a summary of the specification, including its name, type, file count, and root file. It also lists each file the specification contains, showing its path, type (root or supporting file), size, and content. Add `--json` for machine-readable output.\n\n#### Add workspace dependencies\n\nThe `postman dependency add` command adds a collection, environment, or mock from another workspace as a dependency of your local project, enabling you to reuse it. Pass the element type and its name or ID, for example `postman dependency add collection <nameOrId>`. Add `--json` for machine-readable output.\n\n#### Set up a cloud-backed project without a Postman account\n\nThe `postman init` command now lets you set up a cloud-backed project without being signed in to a Postman account. When you run it while signed out, the CLI creates an anonymous guest session and guest workspace in the Postman Cloud, and binds your project to it. Later, sign up for an account with the `postman signup` command to claim it. If the guest session can’t be created, `postman init` falls back to offering to sign in.\n\n### Improvements\n#### A richer sample mock\n\nWhen you run `postman mock generate` without a source, it now scaffolds a shopping-cart sample mock (`POST /cart/items`, `GET /cart`, `POST /checkout`) that shows how to serve saved examples. This provides a more instructive starting point than the previous single `GET /health` endpoint.\n"},{"version":"1.56.3","content":""},{"version":"1.56.2","content":""},{"version":"1.56.1","content":""},{"version":"1.56.0","content":"## Postman CLI v1.56.0\n\n### What’s New\n#### Check and update agent skills\n\nThe agent skills that `postman init` installs can fall behind the latest published version over time. The new `postman skills status` and `postman skills update` commands check for newer versions and fetch them, without re-running `postman init`. When you work with an AI agent, the installed `SKILL.md` instructs the agent to keep the skills current for you, updating them with your approval.\n\n### Improvements\n#### Redirect requests to a mock in performance tests\n\nThe `postman performance run` command now supports `--use-mock`, which redirects a variable or host to a local code mock or a cloud mock server during a run.\n\n#### Supply Postman Local Vault secrets through environment variables\n\nWhen you run `postman collection run` and a secret from your local vault can’t be resolved (for example, in CI), the CLI now reads that secret from a `POSTMAN_VAULT_<key>` environment variable, if you’ve set one.\n\n#### Initialize your Native Git API project with the latest agent skills\n\nThe `postman init` command now fetches the agent skills it installs from the Postman skills repository instead of using copies built into the CLI.\n\n#### Have your AI agent build your API specification\n\nThe `postman init` command no longer generates an API specification from your source code. Instead, the installed `SKILL.md` guides your AI agent to build the specification from your code.\n\n#### Connect a workspace during application test setup\n\nWhen you run `postman app test` with result reporting (`--report-events`) enabled (the default) but no workspace is connected, the command now walks you through connecting one. In CI or non-interactive environments, it prints setup instructions and exits.\n"},{"version":"1.55.0","content":"## Postman CLI v1.55.0\n\n### What’s New\n#### Sync flows with `postman workspace push`\n\nThe `postman workspace push` command now syncs flows to the linked Postman workspace, alongside your other workspace elements.\n\n### Improvements\n#### Stronger SSRF protections in the monitoring runner\n\nThe `postman runner start` command now has stronger protections against server-side request forgery (SSRF). Addresses on your own internal network remain reachable.\n\n#### Flat environment files for `postman mock run`\n\nThe`postman mock run` command now accepts flat `key: value` environment files (with `-e`), in addition to the Postman environment format.\n\n### Bug Fixes\n\n- Fixed silent failures when loading an environment file with `postman mock run -e`. Loading a missing file, a parse error, or an unexpected shape now returns a clear, specific error.\n- Fixed `postman mock deploy` resetting a redeployed mock server’s visibility and auto-deploy settings. If you didn’t pass `--public`, it would set visibility to private. If you didn’t pass `--auto-deploy`, it would set auto-deploy to off. It now keeps the existing settings and shows the current values and what changed.\n- Fixed a newly created cloud mock showing a \"source not available\" placeholder in the editor. It now includes a default scenario and handler.\n- Fixed API key validation for deployments that set `POSTMAN_API_BASE_URL`, so the CLI validates your key against your deployment’s base URL instead of the public region URLs.\n"},{"version":"1.54.2","content":""},{"version":"1.54.1","content":""},{"version":"1.54.0","content":"## Postman CLI v1.54.0\n\n### What’s New\n#### Set up an AI-ready API project with `postman init`\n\nThe new `postman init` command sets up a Postman Native Git API project on your machine in one step. It can generate a starting API specification from your code and adds a SKILL.md that teaches agents how to build and test APIs with the Postman CLI. If you’re signed in, `postman init` offers to create a new Postman workspace and connect your project to it so you can collaborate with your team.\n\n#### Create a Postman workspace with `postman workspace create`\n\nThe new `postman workspace create` command creates a Postman workspace and connects your local Git repository to it. You can then push your project to the workspace and pull updates back, so your team can collaborate on it in Postman. By default, it names the workspace after your Git remote and connects the current directory.\n\n#### Run GraphQL and gRPC request blocks in Postman Flows\n**Available on Enterprise plans**\n\nThe `postman flows run` command now runs GraphQL and gRPC request blocks, in addition to HTTP, using your existing authentication and environment settings. GraphQL request blocks support queries and mutations, but not subscriptions. gRPC request blocks support unary methods, but not streaming methods.\n\n### Improvements\n#### Sync code mocks and simulations with `postman workspace push`\n\nThe `postman workspace push` command now syncs code mocks and simulations to the linked Postman workspace, matching the app’s Git sync.\n"},{"version":"1.53.0","content":"## Postman CLI v1.53.0\n\n### What’s New\n#### Lint AsyncAPI specifications\n\nThe `postman spec lint` command now supports AsyncAPI specifications (versions 2.x and 3.x), in addition to OpenAPI. Provide an AsyncAPI document to validate it and identify any issues.\n\n#### Manage cloud mocks\n\nThe `postman mock` commands now work with cloud mocks as well as local ones. Pass a mock’s ID to the `get`, `run`, or `delete` command to act on a cloud mock (a file path still targets a local mock). The `list` and `generate` commands accept a new `--workspace` option to list and create mocks in a Postman workspace.\n\n#### Deploy a cloud mock to a mock server\n**Available on Solo, Team, and Enterprise plans**\n\nThe new `postman mock deploy <mockId>` command publishes a cloud mock to a mock server. Run it interactively to set the mock server’s name, slug, and visibility, or pass those as options to deploy from a script.\n\n#### Browse a mock server’s request history\n**Available on Solo, Team, and Enterprise plans**\n\nThe new `postman mock log <mockServerId>` command shows a deployed mock server’s request and response history, newest first. Filter the entries by method, status, path, or time window with `--method`, `--status`, `--path`, `--since`, and `--until`. Use `--limit` to cap how many entries appear, or `--json` for machine-readable output. You can find the mock server ID with `postman mock get`.\n\n#### Run setup and teardown collections in cloud performance tests\n**Available on Solo and Team plans**\n\nThe `postman performance run` command accepts `--setup-collection <id>` and `--teardown-collection <id>` to run a collection before and after a performance test. These apply to Postman Cloud performance tests (`--runner postman-cloud`).\n"},{"version":"1.52.0","content":"## Postman CLI v1.52.0\n\n### Improvements\n#### Event reporting is on by default\n\nThe Postman CLI now reports events to Postman by default across the commands that emit them, from run, test, and lint results to usage analytics. To opt out, pass `--report-events=false`.\n\n#### Get syntax results even when governance rules can’t be applied\n\nThe `postman spec lint` command now returns syntax results even when it can’t apply governance rules, such as when you’re not signed in or the governance rulesets can’t be retrieved.\n"},{"version":"1.51.1","content":"## Postman CLI v1.51.1\n\n### What’s New\n#### Work with datasets in the Postman CLI\n**Available on Solo, Team, and Enterprise plans**\n\nWith the `postman dataset` commands, you can manage reusable test data, from static files to live databases, and use it to drive data-driven collection and performance runs from the Postman CLI, including in CI/CD.\n\n#### Redirect requests to a mock during a collection run\n\nThe `postman collection run` command now supports a `--use-mock` option that redirects requests to a mock while the collection runs. Each mapping points a URL to a local mock (`mock:<path or id>`) or a deployed mock server (`mock-server:<id>`), and you can pass `--use-mock` more than once to redirect multiple URLs. When a mapping points to a local mock, the Postman CLI starts it for you.\n"},{"version":"1.51.0","content":"## Postman CLI v1.51.0\n\n### Bug Fixes\n\nFixed a regression in v1.50.0 that caused `postman spec lint` to fail for API Governance users migrated to the new experience.\n"},{"version":"1.50.0","content":"## Postman CLI v1.50.0\n\n### What’s New\n#### Run performance tests in the Postman Cloud\n**Available on Solo and Team plans**\n\nThe `postman performance run` command now supports a `--runner` option that selects where a performance test’s load originates. By default, load originates from the machine that invokes the command. Use `--runner postman-cloud` to generate load from Postman’s managed cloud infrastructure instead.\n\n#### Use datasets in performance tests\n**Available on Solo, Team, and Enterprise plans**\n\nThe `postman performance run` command now supports datasets as a test data source. Use `--dataset-id` and `--dataset-view-id` to select a dataset and view, and `--dataset-distribution` to control how rows are assigned to virtual users (`round-robin`, `fixed`, or `random`).\n\n#### Connect a workspace to a Git repository\n\nThe new `postman workspace connect-git` command binds a Postman workspace to a Git repository on your machine. Connect the repository first, then use `postman workspace push` and `postman workspace pull`.\n\n#### Pull a workspace to your local folder\n\nThe new `postman workspace pull` command pulls a workspace’s collections, environments, specifications, and other elements into your local Git repository. It is the counterpart to `postman workspace push`. If the Git repository isn’t already connected to the workspace, Postman creates the connection before pulling.\n\n#### More ways to work with local mocks\n\nYou can now list, inspect, and delete local mocks with the new `postman mock list`, `postman mock get`, and `postman mock delete` commands. The `postman mock generate` command now generates a sample mock with a `GET /health` endpoint when you run it without a collection or specification file, providing a runnable starting point for you to edit.\n\n#### Set up Playwright network capture automatically\n\nThe new `postman app setup-capture` command sets up Playwright network capture for you. It finds your Playwright config, installs the `postman-playwright` package, and wraps your config with `withPostman()`. The `postman app test` command also runs this as an interactive preflight check.\n\n### Improvements\n#### Autofix workspace lint issues\n\nThe `postman workspace lint` command now has a `--fix` option that applies safe autofixes to repairable lint issues.\n\n### Bug Fixes\n\nFixed an issue where the JSON and HTML reports were missing run timings (`run.meta.duration` was null). Run timings are included again.\n"},{"version":"1.49.0","content":"## Postman CLI v1.49.0\n\n### What’s New\n#### Lint your workspace before pushing\n\nThe `postman workspace push` command now runs a lint check before pushing. It blocks the push if your workspace configuration has lint errors, and skips any entity that has lint errors while still pushing the clean ones.\n\n#### Set up application tests interactively\n\nIf you run `postman app test` without a configuration file or collections, the command now guides you through an interactive setup instead of exiting. You can select existing collections or generate a new collection from your test traffic, complete with auto-generated test scripts.\n\n#### Author scripts and inspect script outcomes for webhooks\n\nYou can now author and update a webhook’s scripts with the new `postman webhook scripts set` command. The `postman webhook requests describe` command now includes a test report, and adding the `--verbose` option streams the script execution logs.\n\n### Improvements\n#### Install-aware update instructions\n\nWhen an update is available, the Postman CLI now detects whether it was installed with npm or as a direct download, and shows the matching update instructions.\n"},{"version":"1.48.0","content":"## Postman CLI v1.48.0\n\n### What’s New\n#### Lint your entire local workspace\n\nThe `postman workspace lint` command lints your whole local workspace in one report: the workspace configuration plus every collection, spec, environment, and globals file. Use `--meta` to lint only the workspace configuration.\n\n#### Track the deployed version in application tests\n\nThe `postman app test` command can now record which deployed version of your application each test run exercised, so you can correlate results with specific deployments. Provide the version with the `--deployed-version` option, or from your Playwright report metadata.\n\n### Bug Fixes\n\n- Fixed an unclear error when a cloud performance run requested fewer virtual users than the minimum allowed. The `postman performance run` command now explains the minimum virtual-user requirement.\n- Fixed an issue where a worker crash could stop a Private API Monitoring runner from processing runs. The runner now recovers automatically.\n"},{"version":"1.47.2","content":"## Postman CLI v1.47.2\n\n### What’s New\n#### Generate API mocks from a Native Git collection directory\n\nThe `postman mock generate` command now accepts a directory containing a Native Git v3 collection, not just a single collection file. You can generate example-rich mocks straight from a Git-synced workspace.\n\n### Improvements\n#### Push documents to your workspace\n\nThe `postman workspace push` command now syncs documents (Markdown files under `postman/documents/`), in addition to the collections, environments, specifications, and globals it already supported.\n\n#### Faster, more secure installs\n\nThe macOS and Linux installers now prompt for your password once instead of several times. All three installers (macOS, Linux, and Windows) now verify the downloaded binary’s signature before installing.\n\n#### Control the port for mock servers\n\nThe `postman mock run` command now supports a `--port` option. Pass a specific port, or use `--port auto` for a port assigned automatically. If you don’t set a port, the mock uses its configured port and falls back to an available one if that port is busy.\n\n### Bug Fixes\n\nFixed an issue where the `postman mock run` command served v3 example bodies as a raw `{ type, content }` object instead of the example’s actual payload.\n"},{"version":"1.47.0","content":"## Postman CLI v1.47.0\n\n### What’s New\n#### Generate a local code mock from a collection or spec\n\nYou can now generate a local code mock from a Postman collection or an OpenAPI spec with the new `postman mock generate` command. It needs no Postman account or network access to generate or run, so you can use it in CI/CD. Run the generated mock with `postman mock run`.\n\n### Improvements\n#### Code mock responses now match the Postman app\n\nCode mock examples now serve their actual response headers and content types instead of always using `application/json`. Simulated fault responses, such as chaos and error conditions, also return the same status code and body as the app.\n\n#### Expanded Private API Monitoring runner support for collections\n\nPrivate API Monitoring runners can now monitor collections that contain not just HTTP requests, but gRPC and GraphQL requests as well. Runners now also prefetch vault secrets in bulk at the start of a run for faster execution.\n"},{"version":"1.46.1","content":"## Postman CLI v1.46.1\n\n### What’s New\n#### Generate Swift SDKs\n\nYou can now generate Swift SDKs with the Postman CLI, using `postman sdk generate`.\n\n#### Lint local environment and globals files\n\nYou can now validate your environment and globals files with the new `postman environment lint` and `postman globals lint` commands.\n\n### Improvements\n#### Push global variables to your workspace\n\nThe`postman workspace push` command now pushes your workspace’s global variables, in addition to the collections, environments, and specifications it already supported.\n\n### Bug Fixes\n\nFixed an issue where TypeScript code in flow **Evaluate**, **If**, and **Condition** blocks failed to run from the CLI. Scripts authored in TypeScript are now transpiled to JavaScript before they run, so type annotations no longer cause errors.\n"},{"version":"1.46.0","content":"## Postman CLI v1.46.0\n\n### Improvements\n#### Better performance run links and output\n\nPerformance run links now point to the correct regional web host, so users in the EU are taken to the EU app instead of the US app. The CLI no longer opens a browser automatically for the live view. It prints the link instead, so you stay in the terminal. Performance runs now default to a one-minute duration, and the output includes hints for the default options.\n\n#### YAML support for code mock configuration files\n\nSupport for writing code mock configuration files in YAML (`.yaml` or `.yml`) has been added to the CLI. Existing JSON configuration files continue to work without changes.\n\n#### Search workspace documents\n\nYou can now search workspace documents from the CLI with the `postman search` command.\n\n### Bug Fixes\n\n- Fixed an issue where webhook commands did not recognize API key authentication.\n- Fixed an issue where `postman workspace push` could not resolve a spec’s path to its cloud ID and skipped the spec-to-collection link.\n"},{"version":"1.45.1","content":""},{"version":"1.45.0","content":"## Postman CLI v1.45.0\n\n### What’s New\n#### AsyncAPI SDK generation from the CLI\n\nYou can now generate SDKs from AsyncAPI specifications directly using the Postman CLI. You can only generate SDKs in languages that support AsyncAPI, helping you avoid errors when selecting an output language.\n\n#### List your workspaces from the CLI\n\nYou can now use the `postman workspace list` command to list all the Postman workspaces you have access to, showing each workspace’s ID, visibility type, and name. Use `--filter <name>` to narrow results by name. You can add `--json` to return the results in JSON format.\n\n### Improvements\n#### More reliable flow execution when collections are reorganized\n\nThe Postman CLI now runs flows correctly even when the requests they reference have been moved or renamed in a collection. Previously these runs failed with an error that the collection items could not be found, which blocked CLI automation and CI/CD workflows. This brings CLI flow runs in line with how the same flows already run in the Postman app. If a flow still reports this error, re-save it in the Postman app to update it to the current format.\n\n### Bug Fixes\n\nFixed an issue where streamed response bodies were dropped during flow capture preloading, which could cause incomplete data to be recorded during flow execution.\n"},{"version":"1.44.0","content":"## Postman CLI v1.44.0\n\n### Improvements\n\n#### Control how workspace elements sync to the cloud\n\nThe `postman workspace push​` command now supports a `--push-strategy` option that gives you more control over how your local Git repository syncs to the Postman cloud. Use the `--push-strategy force-sync` option to mirror your local Git repository. This creates and updates elements in the Postman cloud, and also deletes elements from the cloud that have no local counterpart. When running in a CI/CD pipeline, you can pair `force-sync` with `--yes` to skip the interactive confirmation.\n\n#### Scoped traffic filters for application test runs\n\n**Available on Solo, Team, and Enterprise plans**\n\nThe `filters` configuration in `postman.config.cjs` now supports scoped array entries. Each entry in the array can target specific tests by file path or Playwright tag. This enables you to exclude different URLs, methods, and headers depending on which tests are running. Filters with no `target` or `tags` field apply to all tests.\n\nThe filters configuration still supports a single object that's applied to all tests.\n\n### Deprecated Features\n\n#### Path options deprecated for workspace commands\n\nThe `--collections-dir` and `--environments-dir` options are deprecated for the `postman workspace prepare` and `postman workspace push` commands.\n"},{"version":"1.43.0","content":"## Postman CLI v1.43.0\n\n### What’s New\n#### Raw run data streaming for v3 collections\n**Available as a beta feature on Enterprise plans**\n\nYou can now use the `postman collection run` command with the `--output` option to stream raw run data to YAML files on disk as each request finishes.\n\n#### Manage webhook requests with the Postman CLI\nThe `postman webhook requests` command is now available to help you manage requests received by a webhook. You can list requests, inspect request details, and replay requests for testing and debugging.\n\n#### Report CLI events to Postman\nThe `postman collection run` and `postman spec lint` commands now support a `--report-events` option that uploads run results and governance rule violations to Postman, where you can view them in the API Catalog.\n"},{"version":"1.43.0-canary-260720-162918","content":""},{"version":"1.41.2","content":"## Postman CLI v1.41.2\n\n### Improvements\n#### Improved CLI error output for application test runs\n\nThe `postman app test` command now displays clearer, more informative error messages in the CLI output to help you identify and resolve issues more quickly.\n\n"},{"version":"1.41.1","content":"## Postman CLI v1.41.1\n\n### Improvements\n#### Richer Git metadata for application test runs\nThe `postman app test` command now automatically captures Git metadata for each test run, including commit information, tags, parent commits, `git describe` output, Git notes, and whether the working tree has uncommitted changes. This information is included with the run's analytics without requiring any extra configuration.\n\nThe captured metadata makes it easier to associate test runs with specific commits and releases. For example, you can identify release builds by tagged commits or use your own tag naming convention to determine which runs correspond to a release. In CI environments, the command also captures Git metadata from supported CI providers when available.\n"},{"version":"1.41.0","content":"## Postman CLI v1.41.0\n\n### What’s New\n#### Control automatic pull request creation\nThe `postman sdk connect` command now supports the `--auto-update-pull-requests` option to control whether pull requests are created automatically when the source changes or a new version of the SDK Generator is released. When this option is set to `false`, pull requests are created only when SDK regeneration is triggered manually.\n\nIf you don't specify the option, the default behavior depends on your Postman plan. It defaults to `true` for Enterprise plans and `false` for Team plans.\n\n#### Prevent duplicate elements when pushing to a workspace\nThe `postman workspace push` command now helps prevent accidental duplicate Postman elements. If an element with the same name already exists in the Postman cloud, you're prompted to update the existing element, keep both, or skip it.\n\n### Improvements\n#### Automatic npm publishing for generated SDKs\nThe `postman sdk connect` command no longer needs the `--enable-publishing` option. Generated SDKs now include the npm publishing workflow by default. To publish packages automatically, configure the required GitHub Actions secrets in the connected repository.\n\n#### Improved logging for workspace commands\nThe `postman workspace prepare` and `postman workspace push` commands now support the `--verbose` option to display detailed logs, including API requests and responses, internal actions, and additional troubleshooting information. Error messages have also been improved to make issues easier to understand and resolve.\n\n### Bug Fixes\n- Fixed an issue where the `postman collection run` command could incorrectly skip requests containing valid path variables or query parameters.\n\n- Fixed an issue where `pm.environment.name` and `pm.environment.id` returned `undefined` in scripts.\n"},{"version":"1.40.0","content":"## Postman CLI v1.40.0\n\n### What’s New\n#### Create and query datasets with the Postman CLI\n**Available as a beta feature**\n\nThe Postman CLI now supports the `postman dataset` command for creating datasets, managing data sources, running SQL queries, and running saved views. Datasets enable you to work with reusable data from files and databases in local development and automation workflows, including CI/CD pipelines.\n\nYou can also use the `--iteration-data-dataset`, `--iteration-data-view`, and `--dataset` options with the `postman collection run` command to run collections using dataset-backed iteration data or make datasets available to collection scripts.\n\nTo learn more, see [Dataset commands](https://learning.postman.com/docs/postman-cli/postman-cli-datasets).\n\n### Improvements\n#### Postman Flows cloud runs for non-Enterprise users  \nPostman Flows cloud runs are now available to non-Enterprise users. Users can run a deployed flow via `postman flows run <flow-id>` without needing a private runner, with improved error feedback.\n"},{"version":"1.39.2","content":""},{"version":"1.39.1","content":"## Postman CLI v1.39.1\n\n### Improvements\n#### Automatic SDK version selection\nThe `--sdk-version` option is now optional in the `postman sdk generate` command. If omitted, Postman automatically determines the SDK version based on changes to the API specification, collection, or SDK Generator, and defaults to `1.0.0` for the first generation.\n\n#### Specification lint support for the new API Governance experience\nThe `postman spec lint` command now also supports the new API Governance experience.\n\n### Bug Fixes\n- Fixed an issue where `postman flows run` could return a `Missing required inputs` error when a flow contained unconnected input ports.\n\n- Fixed an issue where using `pm.environment` in scripts would return `undefined` values incorrectly.\n"},{"version":"1.39.0","content":"## Postman CLI v1.39.0\n\n### What’s New\n#### Manage webhooks directly from the Postman CLI\nYou and your agents can now create, manage, and work with Postman webhooks directly from the Postman CLI using the `postman webhook` commands.\n\nThe Postman CLI supports creating, listing, and deleting webhooks in a workspace, along with viewing webhook status and starting or pausing them as needed.\n\nYou can also configure forwarding of events received on your webhook to your local server to support development and debugging using the `postman webhook [Webhook ID or URL] forward [your-local-port]` command.\n\n#### Search mocks and environments with the Postman CLI\nThe Postman CLI now supports `postman search mocks` and `postman search environments`, making it easier to find and reference mocks and environments in your CI/CD pipelines, automation workflows, scripts, and AI agents.\n\n### Improvements\n#### Save Postman Flows test results as an HTML report\nWhen running flows from the CLI, you can now save test results as a self-contained HTML report by passing `--reporters html` to `postman flows run`. The report includes a summary of passed, failed, and skipped tests, per-block results, and full details for any failed assertions.\n\n#### Improvements to reporting test runs in the Application Inventory\nThe `postman app test` command now supports the `--report-events` option for reporting test results and analytics from local test runs to Postman's Application Inventory.\n\nPostman recommends using the `--report-events` option instead of `CI=true`.\n\n#### Run flows that use the Response block's Send/Run input\nFlows that use the new **Send** input on the **Response** block now run correctly from the Postman CLI. This input lets a **Response** block trigger a downstream block on a failed or conditional response without adding a separate **HTTP Request** block.\n\n### Bug Fixes\nFixed an issue that caused the `postman app test` command to return an OOM error when running large test suites.\n"},{"version":"1.38.1","content":"## Postman CLI v1.38.1\n\n### What’s New\n#### Improved output for Postman Flows test results\nWhen running flows from the CLI, test results are now displayed in a clean, readable format instead of raw JSON.\n\n#### Analyze specific test run artifacts\nThe `postman app test` command now supports passing a Playwright JSON report file directly with the `--network-log` option. This makes it easier to analyze a specific test run without relying on automatic artifact discovery.\n\nTo learn more, see [Application commands](https://learning.postman.com/docs/postman-cli/postman-cli-application).\n\n#### Improved CI context detection for application testing\nApplication testing now more accurately detects CI context across local environments and GitHub workflows, including pull request and push-triggered runs. This helps ensure test results are correctly associated with the originating branch, commit, and workflow context.\n"},{"version":"1.38.0","content":"## Postman CLI v1.38.0\n\n### Improvements\n#### Live performance metrics for Postman CLI runs\n**Available on Solo, Team, and Enterprise plans**\n\nWhen you trigger a performance run using the `postman performance run` command, you can now stream live performance metrics in the Postman app as the test runs, either locally or from your CI/CD pipeline. This gives you real-time visibility into slow response times, failed assertions, and request errors as they occur. If the API becomes unstable under load, you can stop the test, adjust your configuration or API, and rerun without waiting for the full run to finish. This helps you catch and address issues early, preventing deployments that don't meet your performance requirements.\n\nTo learn more, see [Configure and validate performance tests using the Postman CLI](https://learning.postman.com/docs/postman-cli/postman-cli-run-performance-test).\n\n### Bug Fixes\nFixed an issue where running `postman sdk generate` against a v3 Postman Collection could produce an empty `items` array.\n"},{"version":"1.37.0","content":"## Postman CLI v1.37.0\n\n### What’s New\n#### Simplified Playwright setup for Application Inventory\nYou can now enable network capture for Playwright tests with a single configuration change using `withPostman` in your `playwright.config.ts` file. This approach works across all pages, contexts, and fixtures without requiring changes to your test files. The Postman CLI automatically processes the resulting network capture output during test runs.\n\nThe existing `attachNetworkCapture` approach remains supported for teams that prefer test-level setup.\n\nTo learn more, see [Integrate your test suite with the Application Inventory](https://learning.postman.com/docs/tests-and-scripts/test-applications/test).\n"},{"version":"1.36.0","content":"## Postman CLI v1.36.0\n\n### What’s New\n#### Integrate your SDK generation with your GitHub repo\n**Available on Team and Enterprise plans**\n\nUse the updated `postman sdk connect` command to connect Postman SDK generation with your GitHub repo and automate subsequent SDK updates. Use `postman sdk connections list` and `postman sdk connections delete` to list and remove your GitHub connections, respectively. Automation is available on Enterprise plans only.  \n\n### Bug fixes\nFixed an issue in Application Inventory where request matching didn't respect environment variables.\n\nFixed an issue where UI tests without network traffic were not being recorded in Application Inventory.\n"},{"version":"1.35.2","content":"## Postman CLI v1.35.2\n\n### Improvements\n#### Application testing improvements\nThe `postman app test` command includes several improvements:\n\n- Configuration is now validated before a run begins, and analytics are reliably sent when a run completes.\n\n- Network request failures captured during a run are propagated through the pipeline instead of being silently dropped.\n\n- The error message shown when no network traffic is captured is clearer.\n\n- Long request names are safely truncated to prevent filesystem errors.\n\nTo learn more, see [Application commands](https://learning.postman.com/docs/postman-cli/postman-cli-application).\n\n#### Support for connector blocks when running flows\nThe `postman flows run` command now requires the `--workspace` option when your flow includes a [connector block](https://learning.postman.com/docs/postman-flows/reference/blocks/connector). Use the `--workspace [workspace-id]` option to specify the workspace by its ID.\n\nTo learn more, see [Flows commands](https://learning.postman.com/docs/postman-cli/postman-cli-flows#postman-flows-run).\n"},{"version":"1.35.1","content":"## Postman CLI v1.35.1\n\n### Improvements\n#### Environment variable resolution for flows\nThe `postman flows run` command now resolves `{{varName}}` environment variables in scenario input values and configuration entries at runtime. Pass a Postman environment file using the `--environment` option and any variables referenced in your flow are substituted with their values. If a variable is referenced but missing from the environment file, the CLI returns an error identifying the unresolved variable by name.\n\nTo learn more, see [Flows commands](https://learning.postman.com/docs/postman-cli/postman-cli-flows#postman-flows-run).\n"},{"version":"1.35.0","content":"## Postman CLI v1.35.0\n\n### What’s New\n#### Application testing and Playwright Integration\n\n**Available on Solo, Team, and Enterprise plans**\n\nTurn your existing Playwright tests into API contract validation with the new `postman app` commands. Use the `postman app init` command to initialize your project and configure your test command, collections, and environments. Use the `postman app test` command, paired with the `postman-playwright` plugin, to observe API traffic during Playwright runs, match each call to requests in your collections, and run your `pm.test` assertions against live responses. Results, unmatched calls, and coverage gaps are pushed to the Application Inventory in a single report.\n\nTo learn more, see [Application commands.](https://learning.postman.com/docs/postman-cli/postman-cli-application)\n\n### Improvements\n#### Improved output options for flows runs\n\nThe `postman flows run` command has two new options for controlling output. Use `--output json` to save execution results, including outputs and logs, to a timestamped JSON file in the current directory. This makes it easier to capture structured output for CI/CD pipelines and scripts. Use `--no-truncate` to display response bodies and payloads in full in the terminal. By default, truncation remains enabled so the terminal experience stays readable.\n\nThe `--json` option is no longer supported. Use `--output json` instead.\n\nTo learn more, see [Flows commands.](https://learning.postman.com/docs/postman-cli/postman-cli-flows#postman-flows-run)\n\n"},{"version":"1.34.5","content":"## Postman CLI v1.34.5\n\n### Bug Fixes\nFixed an issue in the `postman flows run` command where environment variables were overriding request variables defined in the HTTP **Request** block.\n"},{"version":"1.34.4","content":"## Postman CLI v1.34.4\n\n### Bug Fixes\nFixed an issue that caused `postman workspace push --yes` to create new collections or environments when an update request returned a transient 404, instead of failing safely.\n\nFixed an issue where environment IDs in `.postman/resources.yaml` were rewritten from the canonical `<owner>-<uuid>` format to a bare UUID, causing subsequent pushes to fail.\n\nFixed an issue where pushing collections could result in an \"invalid mode\" error.\n"},{"version":"1.34.3","content":"## Postman CLI v1.34.3\n\n### What’s New\n#### Edit and regenerate SDKs\nYou can now edit, add, or delete files in your SDKs and use the `postman sdk generate` command to regenerate the SDK. \n\nTo learn more, see [Generate SDKs from collections and API specifications](https://learning.postman.com/docs/sdk-generator/generate#generate-sdks-from-the-cli). \n\n#### Enable change tracking for SDKs \nThe Postman CLI now supports the `postman sdk track`  command to manage change tracking for SDKs created before the regenerate SDK option was available.\n\n#### Support for HTTP Request blocks with tests in Flows\nThe Postman CLI now supports the v2 HTTP **Request** block when running flows locally with the `postman flows` command. This block adds tests as first class properties of the request.\n\n### Bug Fixes\nFixed an issue with the `postman flows` command where the **Select** block failed when passing structured input values using `--input`, `--input-file`, or `--scenario`. Input values are now correctly parsed as structured types, matching the behavior of the Postman canvas runner.\n\nFixed an issue with the `postman flows` command where request trigger outputs returned an empty map instead of the expected response data.\n"},{"version":"1.34.2","content":""},{"version":"1.34.1","content":"## Postman CLI v1.34.1\n\n### What’s New\n#### Generate SDKs in Kotlin\nYou 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.\n\nTo learn more, see [SDK CLI commands](https://learning.postman.com/docs/sdk-generator/sdk-cli).\n\n### Improvements\n#### Specify folders using paths in collection runs\nThe `-i` option in the `postman collection` command now supports specifying folders with paths.\n\nTo learn more, see [Collection commands](https://learning.postman.com/docs/postman-cli/postman-cli-collections).\n"},{"version":"1.34.0","content":"## Postman CLI v1.34.0\n\n### What’s New\n#### Generate SDKs in Ruby\nIntroduced support for Ruby in the scope of SDK generation.\n\nTo learn more, see [SDK CLI commands](https://learning.postman.com/docs/sdk-generator/sdk-cli).\n\n#### Configure Agent Skills with CLI SDKs\nYou can control whether Agent Skills are generated with the `postman sdk generate` command for a CLI SDK. Use the `sdk.languageOptions.cli.skills` object in your `.postman/config.json` file.\n\nThe `skills` object has an `enabled` Boolean field that determines whether Agent Skills are generated. This value defaults to `true` if not specified or left empty.\n\nTo learn more, see [SDK CLI commands](https://learning.postman.com/docs/sdk-generator/sdk-cli#postman-sdk-generate).\n"},{"version":"1.33.6","content":"## Postman CLI v1.33.6\n\n### What’s New\n#### Generate CLIs from your Postman Collection or API specification\n**Available on Team and Enterprise plans**\n\nYou 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.\n\nTo learn more, see [Generate CLI from your collection or specification](https://learning.postman.com/docs/cli-generator/overview).\n\n#### Specify input data for Postman Flows\nYou 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.\n\nTo learn more, see [Flows commands](https://learning.postman.com/docs/postman-cli/postman-cli-flows).\n"},{"version":"1.33.5","content":""},{"version":"1.33.4","content":"## Postman CLI v1.33.4\n\n### What’s New\n#### Generate SDKs in PHP, Go, and C#\nIntroduced 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.\n\nTo learn more, see [SDK CLI commands](https://learning.postman.com/docs/sdk-generator/sdk-cli).\n\n#### Validate collections in v3 format\nThe Postman CLI now supports the `postman collection lint` command to verify that a collection matches the v3 YAML format.\n\nTo learn more, see [Collection commands](https://learning.postman.com/docs/postman-cli/postman-cli-collections).\n"},{"version":"1.33.3","content":""},{"version":"1.33.2","content":"## Postman CLI v1.33.2\n\n### Bug Fixes\nFixed an issue that caused binary files to become corrupted during collection runs.\n\nFixed an issue that caused collection runs to complete before all output was fully written.\n"},{"version":"1.33.1","content":"## Postman CLI v1.33.1\n\n### Improvements\n#### New options for `postman flows run` and `postman flows trigger`\n\n**Available on Enterprise plans**\n\nTwo new options are now available for the Postman CLI `flows` commands:\n\nUse 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.\n\nUse the `-r, --result` option with `postman flows trigger` to display only the response body from a triggered cloud flow run.\n\nTo learn more, see [Flows commands.](https://learning.postman.com/docs/postman-cli/postman-cli-flows)\n\n### Bug Fixes\nFixed 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.\n\nFixed 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.\n\n"},{"version":"1.33.0","content":"## Postman CLI v1.33.0\n\n### What’s New\n#### Migrate collections from v2.1 to v3 format\n\nThe Postman CLI now supports the `postman collection migrate` command to migrate collections from v2.1 to v3 format.\n\n### Improvements\n#### Sync connected local specifications and collections to the cloud\n\nThe `postman workspace push` command now supports syncing connected local specifications and collections to your workspace in the Postman cloud.\n\n### Bug Fixes\nFixed an issue that prevented local mock servers from starting when using `postman mock run` or `postman collection run --mock.`\n\nFixed an issue that caused the `--color off` option to not work with the `postman collection run` command.\n\n"},{"version":"1.32.0","content":"## Postman CLI v1.32.0\n\n### What’s New\n#### New Postman CLI commands for Flows \n**Available on Enterprise plans**\n\nYou can now manage and monitor your flows directly from the Postman CLI with five new commands.\n\n- Use `postman flows list` to view all flows available in your workspace.\n\n- Use `postman flows deploy` to deploy a flow to the Postman cloud from the CLI.\n\n- Use `postman flows trigger` to trigger execution of a deployed flow.\n\n- 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).\n\n- 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.\n\nTo learn more, see [Postman CLI command options](https://learning.postman.com/docs/postman-cli/postman-cli-options#run-flows).\n\n### Improvements\n#### Improved gRPC schema resolution\nSchema resolution for gRPC is now faster and more reliable.\n\n### Bug Fixes\nFixed an issue where gRPC schemas could get stuck for up to 30 seconds on some servers.\n"},{"version":"1.31.3","content":"## Postman CLI v1.31.3\n\n### What’s New\n\n#### Support for Private API Monitoring with runners\n\n**Available on Enterprise plans**\n\nWith 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.\n\nUse 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.\n\nTo learn more, see [Monitor internal APIs with runners](https://learning.postman.com/docs/monitoring-your-api/runners/overview).\n\n#### Support for running performance tests\nThe 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.\n\nUse 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.\n\nTo learn more, see [Run a performance test using the Postman CLI](https://learning.postman.com/docs/postman-cli/postman-cli-run-performance-test).\n\n#### Support for mock servers\nThe 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`.\n\nYou 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.\n\nTo learn more, see [Postman CLI command options](https://learning.postman.com/docs/postman-cli/postman-cli-options#run-collections).\n\n#### Support for generating SDKs from collections and API specifications\nThe 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.\n\nUse 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.\n\n`postman sdk generate <collection-or-spec-id> --language typescript python --output-dir ./sdks`\n\nTo 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.\n\nAdditional SDK management commands are available:\n\n- `postman sdk list` — List previous SDK builds for a collection or specification.\n- `postman sdk fetch` — Download SDKs from a previous build by its build ID.\n- `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.\n\n#### Support for running flows locally with the Postman CLI \n\n**Available on Enterprise plans**\n\nYou 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.\n\nTo learn more, see [Postman CLI command options](https://learning.postman.com/docs/postman-cli/postman-cli-options#run-flows).\n\n### Improvements\n\n#### Support for multi-protocol collection runs\nThe `postman collection run` command now supports gRPC and GraphQL collection runs.\n\nTo learn more, see [Postman CLI command options](https://learning.postman.com/docs/postman-cli/postman-cli-options#run-collections).\n"},{"version":"1.31.2","content":""},{"version":"1.30.1","content":""},{"version":"1.29.5","content":"## Postman CLI v1.29.5\n\n### Improvements\n- Various internal enhancements were added in this release.\n"},{"version":"1.29.4","content":""},{"version":"1.29.3","content":""},{"version":"1.29.2","content":""},{"version":"1.29.1","content":"## Postman CLI v1.29.1\n\n### Bug Fixes\nFixed an issue that caused the `postman workspace push` command to time out for large files.\n"},{"version":"1.29.0","content":"## Postman CLI v1.29.0\n\n### Improvements\n- Internal and beta feature enhancements were added in this release.\n"},{"version":"1.28.0","content":"## Postman CLI v1.28.0\n\n### What's New\n\n#### Support for running performance tests \n**Running performance tests using the Postman CLI is available as a beta feature.**\n\nThe 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.\n\n"},{"version":"1.28.0-preview.1","content":""},{"version":"1.27.0","content":"## Postman CLI v1.27.0\n\n### What's New\n\n#### Support for Linux ARM64\nThe Postman CLI now supports Linux ARM64.\n\n"},{"version":"1.27.0-preview.1","content":""},{"version":"1.26.0","content":"## Postman CLI v1.26.0\n\n### What's New\n\n#### Syntax validation for API specifications\nThe `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.\n\n#### New \"Issue Type\" column in output\n\nValidation 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.\n\n![](https://st-ar.cdn.postman.com/release-notes/1-26-0/Screenshot-2025-12-02-6.02.56-PM.png)\n\nThe new column is added at the end of CSV, JSON, and table outputs to maintain backward compatibility with existing CI/CD pipelines.\n\n#### Fixed collection push failing due to owner ID mismatch\n\nFixed an issue where `postman workspace push` would fail to update collections when the resource ID format didn't include the expected owner prefix.\n\n"},{"version":"1.26.0-preview.1","content":""},{"version":"1.25.0","content":"## Postman CLI v1.25.0\n\n### What’s New\n#### Run saved requests in scripts with runners\nRunners now support the `pm.execution.runRequest` method that enables you to reference and send requests from your collection's scripts.\n"},{"version":"1.25.0-preview.1","content":""},{"version":"1.24.2","content":"## Postman CLI v1.24.2\n\n### What’s New\n#### Improvements to syncing local elements with workspaces\nThe `postman workspace` commands now support scanning local collection, environment, and specification directories for elements to sync with the Postman cloud. Collections now regenerate their IDs if there's a mismatch between workspaces.\n\n"},{"version":"1.24.1","content":"## Postman CLI v1.24.1\n\n### Bug Fixes\n- Fixed memory stack overflow errors that caused runners to fail during long monitor runs.\n"},{"version":"1.24.0","content":"## Postman CLI v1.24.0\n\n### What’s New\n#### Send HTTP requests from the command line.\nThe Postman CLI now includes a new postman request command that lets you send HTTP requests directly from the command line with full Postman capabilities. Use familiar Postman features like environment variables, authentication methods, pre-request and post-request scripts, and test assertions—all from your terminal.\n\n**Send a simple GET request**\n\n`postman request https://api.example.com/users`\n\nLearn more about [POST with authentication and environment variables](https://learning.postman.com/docs/postman-cli/postman-cli-options/#run-requests).\n\n"},{"version":"1.23.1","content":"## Postman CLI v1.23.1\n\n### What’s New\n#### Added support for linting specifications in EU-region.\nLearn more about [linting API specifications with the Postman CLI](https://learning.postman.com/docs/postman-cli/postman-cli-options/#governance-and-security).\n"},{"version":"1.23.0","content":"## Postman CLI v1.23.0\n\n### What’s New\n\n#### Private API monitoring with runners\n\n**Private API Monitoring is available as a beta feature on all paid plans. Enterprise teams must contact their Postman Customer Success Manager to enable Private API Monitoring**.\n\nYou can now set up runners using the Postman CLI to monitor internal APIs within your own infrastructure. With runners, you can run monitors on your network without exposing internal endpoints to the public internet.\n\nTo start a runner, use the following command:\n\n`postman runner start --id <id> --key <key>`\n\nOnce deployed, runners appear automatically in your monitor configuration and can be used to monitor APIs in restricted networks, isolated VPCs, or private data centers.\n\nTo learn more, see [Set up a runner with the Postman CLI](https://learning.postman.com/docs/monitoring-your-api/runners/configure-a-runner/#set-up-a-runner-with-the-postman-cli).\n"},{"version":"1.22.0","content":"## Postman CLI  v1.22.0\n\n### What’s New\n\n#### [BETA] Workspace Sync Commands\nNew workspace management commands have been introduced as a public beta to sync locally exported and saved collections and environments with Postman workspaces:\n\n- `postman workspace prepare` – Prepares and validates local files for a cloud push.\n\n- `postman workspace push`– Creates, updates, or deletes entities in the target workspace; validates IDs globally; updates local files with server-assigned IDs. (Also runs `prepare` first.)\n\n#### Required Configuration\nA new declarative config file` .postman/config.json` defines the workspace ID and entity paths (collections, environments, specs, flows).\n\nFor example:\n\n`{\n  \"schemaVersion\": \"1\",\n  \"workspace\": {\n    \"id\": \"your-workspace-id\"\n  },\n  \"entities\": {\n    \"collections\": [\"./collections/name.postman_collection.json\"],\n    \"environments\": [\"./environments/name.postman_environment.json\"],\n    \"specs\": [\"./specs/name.yaml\"]\n  }\n}`\n\n#### Flags\n- `--no-prepare`: Skip the prepare step.\n\n- `--yes`: Bypass all prompts (for CI/CD use)."},{"version":"1.22.0-canary.2","content":""},{"version":"1.22.0-canary.1","content":""},{"version":"1.21.0","content":"## Postman CLI v1.21.0\n\n### What's New\n#### Run saved requests in scripts\nThe `pm.execution.runRequest` method is now supported with the Postman CLI. When you use the method to reference a request in your pre-request and post-response scripts, the referenced request now runs when the collection run is triggered by the Postman CLI.\n\nTo learn more, see [Use scripts to send requests stored in your collections](https://learning.postman.com/docs/tests-and-scripts/write-scripts/postman-sandbox-api-reference/#use-scripts-to-send-requests-stored-in-your-collections)."},{"version":"1.20.0","content":"## Postman CLI v1.20.0\n\n### What’s New \n#### Introducing the Postman CLI manual page\n\nThe Postman CLI now supports a manual page with a complete list of supported commands and options. Use the `man postman` command to return the manual page.\n\n#### Support for linting API specifications by path to the root file\n\nThe Postman CLI now supports linting OpenAPI 3.0 specifications using a local file path to the root file. To run the command, use `postman spec lint <path-to-root-file>`. By default, the command lints specifications against API governance rules applied to all workspaces. Use the `--workspace-id` option to lint specifications against API governance rules applied to a particular workspace.\n\n"},{"version":"1.20.0-preview.1","content":""},{"version":"1.20.0-canary.7","content":""},{"version":"1.20.0-canary.6","content":""},{"version":"1.20.0-canary.5","content":""},{"version":"1.20.0-canary.4","content":""},{"version":"1.20.0-canary.3","content":""},{"version":"1.20.0-canary.2","content":""},{"version":"1.20.0-canary.1","content":""},{"version":"1.19.4","content":"## Postman CLI v1.19.4\n\n### Improvements\n#### Improved welcome banner when signing in\nWhen you sign in with the `login` command, the Postman CLI now displays your username, email, and team name.\n\n#### Improved the npm package README file\nUpdated the README file in the Postman CLI npm package with more documentation to help you get started\n"},{"version":"1.19.3","content":""},{"version":"1.19.2","content":""},{"version":"1.19.1","content":"## Postman CLI v1.19.1\n\n### Bug Fixes\n- Improved Unix installation script for enhanced portability and robustness.\n- Fixed an issue that prevented linting all files in multi-file API specifications in Spec Hub.\n\n"},{"version":"1.19.0","content":"## Postman CLI v1.19.0\n\n### What's New\n#### Support for signing in from the browser\nThe Postman CLI now supports securely signing in and authenticating with Postman from the browser. Use the `postman login` command, without the `--with-api-key` option, and Postman prompts you to sign in from the browser.\n\n#### Support for running a monitor\nThe Postman CLI now supports running a monitor in your team. Use the `postman monitor run` command to run the monitor on the Postman cloud and return the results in the terminal. The results are also sent to your monitor's results in the Postman app.\n\n**Note:** The Postman CLI now requires access to the `https://gateway.postman.com` domain. If your network has outbound restrictions, allowlist the domain before upgrading to the latest version.\n\n"},{"version":"1.18.1","content":"## Postman CLI v1.18.1\n\n### Bug Fixes\n- Fixed issues with the `--silent` option during collection runs\n- Deprecation warning for the `--alias` option\n\n"},{"version":"1.18.0","content":"## Postman CLI v1.18.0\n\n### What’s New\n#### Support for specifying the EU region during authentication\nThe Postman CLI now supports using the `--region eu` option with the `login` command to specify that your instance of Postman is hosted in the EU region.\n"},{"version":"1.17.2","content":"## Postman CLI v1.17.2\n\n### Bug Fixes\nImproved the automated region detection and login process to ensure greater reliability and resilience across diverse environments."},{"version":"1.17.1","content":"## Postman CLI v1.17.1\n\n### What's New\n#### Support for linting multi-file OpenAPI 3.0 specifications\n**Available on Enterprise plans**\n\nThe Postman CLI now supports linting [multi-file OpenAPI 3.0 specifications](https://learning.postman.com/docs/design-apis/specifications/add-files-to-a-specification/) against your team's configured API governance rules. To run the command, use `postman spec lint <spec-id>`. Use the `--fail-severity` option to trigger an exit failure code for rule violations at or higher than the specified severity level: `HINT`, `INFO`, `WARNING`, or `ERROR` (default). Use the `--output` option to set the output format to either `JSON` or `CSV`.\n\nLearn more about [linting API specifications with the Postman CLI](https://learning.postman.com/docs/postman-cli/postman-cli-options/#governance-and-security).\n"},{"version":"1.17.0","content":"## Postman CLI v1.17.0\n### What's New\n\n- The Postman CLI now supports targeting the EU region.\n- To use the EU region, simply log in with an EU region API key—the Postman CLI will automatically detect and display the current region in its output.\n  - For commands that support supplying the API key in the command itself, using a key of the EU region will automatically make the Postman CLI use the EU region’s corresponding resources for that invocation.\n- The following commands are currently available on the EU region:\n  - `postman collection run`\n    - Please note that the `--integration-id` option is not supported for this command as integrations are not available on the EU DC yet. \n\n###  Security patches\n- Postman runtime version has been upgraded to version 7.44.1 to address a security vulnerability."},{"version":"1.16.3-canary-monitor-run-1","content":""},{"version":"1.16.1-canary02","content":""},{"version":"1.16.1-canary01","content":""},{"version":"1.16.0","content":"## Postman CLI v1.16.0\n### What's New\n\n- The Postman CLI now supports linting OpenAPI 3.0 [API Specifications](https://learning.postman.com/docs/design-apis/specifications/overview/) taking into consideration rules enforced via workspace groups as per the team's API Governance configuration.\n\n- To use, execute: `postman spec lint <spec-id>`\n\n**Command Line Options**\n\n - `--fail-severity [severity], -f `\nThis option allows the command to exit with a failure status if issues at or above the specified severity level are detected.  \nSeverity levels include: HINT, INFO, WARNING, ERROR (default).\n\n - `--output [format], -o `\nThis option lets you specify the output format of the linting results. This can be either `json` or `csv.`"},{"version":"1.16.0-canary.1","content":""},{"version":"1.15.1-canary01","content":""},{"version":"1.15.0","content":"## Postman CLI v1.15.0\n\n### What's New\n- Postman CLI can now run scripts with external packages – Import packages from npm and JSR in your scripts to enhance your testing and automation workflows.\n\n### Bug Fixes\n- Improved SSL/TLS support for environments with intercepting proxies.\n\n"},{"version":"1.14.1","content":"## Postman CLI v1.14.1\n\n### Bug Fixes\n- Fixed a compatibility issue on Intel-based macOS systems.\n\n- Fixed exit code resolution in api lint and api publish commands."},{"version":"1.14.0","content":"## Postman CLI v1.14.0\n\n### Bug Fixes\n- api publish command now works on Windows by correcting the Git redirect path.\n\n- The Postman CLI now resolves browser-native globals like crypto and TextEncoder reliably, ensuring scripts behave consistently across both the postman app and the CLI."},{"version":"1.13.1","content":"## Postman CLI v1.13.1\n\n### What's New\n- Users can now filter iterations and requests in HTML reports, making test result analysis easier. The available filters include options to view iterations with `errors or test failures or only test failures` as well as options to filter requests with `errors or test failures or only errors`.\n\n- Users can now trace HTTP request failures in scripts at collection and folder levels in the new JSON reporter.\n\n#### UI & UX Improvements\n- Various design enhancements to make the HTML reports more intuitive, visually appealing, and user-friendly.\n\n"},{"version":"1.13.0","content":"## Postman CLI v1.13.0\n\n### What’s New\n- We’re excited to announce that Postman CLI now also supports HTML as a built-in reporter, enabling you to generate local HTML reports for your collection runs seamlessly. Our other available reporters include JSON, JUnit and CLI.\n`postman collection run <collection-id> --reporters html`\n`postman collection run <collection-id> -r html`\n\n"},{"version":"1.12.0","content":"## Postman CLI v1.12.0\n\n### What’s New\n- We’re excited to announce that Postman CLI now supports built-in reporters, enabling you to generate local reports for your collection runs seamlessly. Available reporters: JSON, JUnit and CLI.\n`postman collection run <collection-id> --reporters json,junit,cli`\n`postman collection run <collection-id> -r json,junit,cli`\n- The JSON reporter introduces a new, compact schema that provides key information on the run execution and failures. Additionally, for workflows built around Newman, reports can also be generated with the Newman JSON schema using the following command.\n`postman collection run <collection-id> -r json --reporter-structure newman`\n\n"},{"version":"1.11.0","content":"## Postman CLI v1.11.0\n\n### What’s New\n- Added support for `await` in top level scripts.\n\n"},{"version":"1.10.3","content":""},{"version":"1.10.2","content":"## Postman CLI v1.10.2\n\n### Bug Fixes\n- Improved reliability in loading packages.\n\n"},{"version":"1.10.1","content":"## Postman CLI v1.10.1\n\n### Bug Fixes\n- Improved reliability in loading collections, environments, etc.\n- Add additional logging for failures in loading test data and packages.\n\n"},{"version":"1.10.0","content":"## Postman CLI v1.10.0\n\n### Bug Fixes\n- Improvements in loading collections, environments, etc, have been made, which will lead to fewer errors while loading them.\n\n"},{"version":"1.9.0","content":"## Postman CLI v1.9.0\n\n### What’s New\n- Added support for publishing API versions with API definition files authored outside Postman for privately hosted repositories.\n- You can now set the next request using `pm.execution.setNextRequest()`, instead of using the deprecated function `postman.setNextRequest()`.\n\n"},{"version":"1.8.0","content":"## Postman CLI v1.8.0\n\n### What’s New\n- You can now run collections that reuse code in scripts by leveraging Packages.\n\n\n"},{"version":"1.7.1","content":"## Postman CLI v1.7.1\n\n### Bug Fix\n- Fixed a bug that was causing requests sent via `pm.sendRequest` to override the collection request URL in the run results summary.\n\n\n\n\n"},{"version":"1.7.0","content":"## Postman CLI v1.7.0\n\n### What’s New\n- You can now run collections containing requests which use files directly from your Postman team. No more manually passing files back and forth with your teammates!\n\n\n"},{"version":"1.6.0","content":"## Postman CLI v1.6.0\n\n### What’s New\n- You can now stop the execution of a particular request using `pm.execution.skipRequest()` in the pre-request script - [#8929](https://github.com/postmanlabs/postman-app-support/issues/8929)\n- You can now access the name of the request, folder, or collection that’s executing the current script using pm.execution.location.current or the entire path using `pm.execution.location` - [#6926](https://github.com/postmanlabs/postman-app-support/issues/6926)\n\n"},{"version":"1.5.0","content":"## Postman CLI v1.5.0\n\n### What's New\n- You can now lint AsyncAPI schemas using the Postman CLI.\n\n"},{"version":"1.4.1","content":"## Postman CLI v1.4.1\n\n### Bug Fixes\n- We have added some improvements to address an identified vulnerability.\n\n\n\n"},{"version":"1.4.0","content":"## Postman CLI v1.4.0\n\n### What’s New\n- You can now use JWT authentication and NTLMv2 authentication in requests while running collections on Postman CLI.\n- You can now run collections with Promises and async/await statements in pre-requests and test scripts - [#4131](https://github.com/postmanlabs/postman-app-support/issues/4131)\n- You can now run collections with requests that support comments in the raw body - [#12379](https://github.com/postmanlabs/postman-app-support/issues/12379)\n\n### Bug Fixes\n- Fixed a bug where Postman CLI exits a run with an error in case one or more requests in the custom order of a collection run are not found. Postman CLI now gracefully handles the error, and such requests will fail to execute in the run.\n\n"},{"version":"1.3.0","content":""},{"version":"1.2.1","content":"## Postman CLI v1.2.1\n\n### What's New\n- We have added support for linting with Governance Custom Functions - [#12191](https://github.com/postmanlabs/postman-app-support/issues/12191)\n\n"},{"version":"1.2.0","content":"## Postman CLI v1.2.0\n\n### What's New\n- `postman api lint <api-id>` now supports linting results taking into consideration rules enforced via workspace groups as per the team's API Governance configuration\n\n### Bug Fixes\n- Fixed a bug where API publish was not working on Windows OS\n\n\n\n\n\n"},{"version":"1.1.2","content":"## Postman CLI v1.1.2\n\n### What's New\n- Postman CLI now supports API version publish action\n  - Running `postman api publish <api-id> --name <version-name>` will publish API contents\n\n\n\n\n\n"},{"version":"1.1.1","content":"## Postman CLI v1.1.1\n\n### What's New\n- Postman CLI can now work with multiple APIs present in one repository\n- Run `postman api lint` without an <api-id> argument\n  - if only one API is present in the repo\n    - lints the API and sends the result back to Postman (if the API utilizes Postman’s git integration and integration-id is provided)\n  - if multiple APIs are present in the repo\n    - lints all the APIs, but does not send the result back to Postman\n- Results provided by the `postman api lint command` only support rules added to the “All workspaces” workspace group in Postman\n\n### Bug Fixes\n- Fixed an issue with git error leaking in local collection runs - `fatal: not a git repository (or any of the parent directories): .git`\n\n"},{"version":"1.1.0","content":""},{"version":"1.0.9","content":""},{"version":"1.0.8","content":""},{"version":"1.0.7","content":""},{"version":"1.0.6","content":""},{"version":"1.0.5","content":""},{"version":"1.0.4","content":""},{"version":"1.0.3","content":""},{"version":"1.0.2","content":""},{"version":"1.0.1","content":""},{"version":"1.0.0","content":""},{"version":"0.0.19","content":""},{"version":"0.0.18","content":""},{"version":"0.0.17","content":""},{"version":"0.0.15","content":""},{"version":"0.0.13","content":""},{"version":"0.0.12","content":""},{"version":"0.0.11","content":""},{"version":"0.0.10","content":""},{"version":"0.0.9","content":""},{"version":"0.0.8","content":""},{"version":"0.0.7","content":""},{"version":"0.0.6","content":""},{"version":"0.0.4","content":""},{"version":"0.0.3-prod01","content":""}]}