Export Postman Collection: UI, API, Git, and CLI Guide

To export Postman collection data in the desktop or web app, open Collections, select the collection’s actions menu, choose More > Export collection (wording can vary slightly by app version), and download the JSON file. Export environments separately from the Environments section.

That is the quick answer. The rest of this guide explains formats, variables, secrets, API retrieval, Git workflows, and how to prove the exported collection still runs.

Export Postman collection data from the app

Postman’s current export documentation describes this flow:

1. Open Collections in the sidebar.
2. Open the actions menu beside the collection.
3. Select More, then Export collection.
4. Choose Export JSON and save the file.

Some Postman versions ask you to choose Collection v2 or v2.1 during export. Newer Git-native workflows can also use a v3 YAML representation. If another tool will consume the file, check which format it accepts before exporting or migrating.

Use a descriptive filename:

billing-api.postman_collection.json

Avoid names such as export.json or final-final.json. The collection’s internal info.name remains useful, but filenames matter in repositories, build logs, and command-line workflows.

What the exported JSON contains

A collection export can contain:

• folders and saved requests;
• methods, URLs, headers, and request bodies;
• collection variables;
• pre-request and post-response scripts;
• saved examples and descriptions;
• authentication configuration;
• the collection format schema URL.

Inspect the top-level structure without printing secrets to a shared terminal log:

jq '{name: .info.name, schema: .info.schema, item_count: (.item | length)}' \
  billing-api.postman_collection.json

A typical v2.1 export starts like this:

{
  "info": {
    "name": "Billing API",
    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
  },
  "item": []
}

The file is executable configuration, not only documentation. Scripts can run code, and requests can call external systems. Review untrusted collections before importing or running them.

Export environments separately

Exporting a Postman collection does not automatically create the environment file your requests may need. To export an environment:

1. Open Environments.
2. Select the environment.
3. Open its actions menu and choose Export.

Use a matching name:

billing-api.local.postman_environment.json

Keep production environments out of source control unless your security policy explicitly permits the non-secret structure and an automated scan proves no sensitive value is present.

Postman variables can exist at several scopes. A collection export can carry collection variables, while environment variables live in a different file. Postman’s variable documentation also supports secure variables and vault secrets for sensitive data.

Check for secrets before committing

Search for risky key names, but treat this as a first pass rather than proof that the file is safe:

jq -r '.. | objects | to_entries[]? | select(
  (.key | ascii_downcase | test("token|secret|password|api.?key"))
) | .key' billing-api.postman_collection.json

Then inspect:

• authorization headers;
• request bodies and query parameters;
• collection and environment variables;
• scripts that assign tokens;
• saved examples copied from real responses.

Replace credentials with variable references such as {{api_token}}. Store the actual value in an approved secret manager or Postman Vault, not in the exported collection.

Collection v2, v2.1, and v3

The right format depends on the next tool in the workflow.

Postman’s current collection CLI documentation includes commands for migrating a v2.1 JSON collection to v3 YAML and linting v3 collections. Do not migrate the only copy of a collection without checking the tools that publish or run it.

The schema URL in info.schema identifies a JSON collection’s declared version. A filename alone does not.

Retrieve a collection with the Postman API

Use the Postman API when a controlled job needs the current cloud collection. Create a Postman API key with the minimum access required and supply the collection UID:

curl --fail --silent --show-error \
  --header "X-API-Key: ${POSTMAN_API_KEY}" \
  "https://api.postman.com/collections/${POSTMAN_COLLECTION_UID}" \
  --output billing-api.postman-api-response.json

The response wraps the exported collection in a top-level collection property. Extract the collection itself before passing it to tools that expect a normal collection file:

jq '.collection' billing-api.postman-api-response.json \
  > billing-api.postman_collection.json

Do not print POSTMAN_API_KEY or store it in a shell script committed to the repository. The official Postman API collection reference documents the collection-ID request and response.

Verify the download before replacing a tracked file

An HTTP 200 does not prove the response is the collection you expected. Check its name, schema, and item count:

jq -e '
  .info.name == "Billing API" and
  (.info.schema | contains("collection")) and
  (.item | type == "array")
' billing-api.postman_collection.json

Write the API response to a temporary location, validate it, and only then replace the tracked artifact. This prevents an error response, empty collection, or wrong collection ID from overwriting the usable file.

Put a collection in Git

An exported Postman collection can be reviewed like code if the team applies a few rules:

postman/
├── billing-api.postman_collection.json
├── billing-api.example.postman_environment.json
└── README.md

The example environment should contain non-secret placeholder values. A short README can state the expected Postman/CLI version, how to supply secrets, which service environment the requests target, and the command used in CI.

In review, look beyond line count:

• Did an endpoint, method, or request body change?
• Did a script start sending data to a new host?
• Did authentication move to a different scope?
• Did saved response data introduce personal or secret values?
• Did a test assertion disappear?
• Does the collection still match the deployed API contract?

Large JSON reordering makes those changes hard to see. Standardize how the team exports or use Postman’s Native Git workflow so collection changes follow the same branch and pull-request path as the API implementation.

Run the exported collection locally

An export is useful only if it can be imported or executed. Postman’s CLI can run a local collection file:

postman collection run postman/billing-api.postman_collection.json \
  --environment postman/billing-api.example.postman_environment.json

Confirm the exact options with the CLI version installed in your environment. The official collection-run guide covers local and CI execution.

For CI, inject environment-specific secrets at runtime. Do not commit a generated production environment just because the pipeline needs variables.

Decide what a successful run proves

A collection run may target:

• a local server with disposable data;
• a mock server that proves request shape but not the backend;
• a staging API with controlled credentials;
• production read-only endpoints under a tightly scoped account.

State which one the pipeline uses. A green mock run does not prove production authentication, networking, database writes, or provider integration.

Keep exports synchronized

Choose one source of truth and make the direction explicit.

Postman cloud as source

Retrieve the collection through the API, validate it, run it, and open a pull request when the tracked file changes. Record the collection UID in configuration, not in several ad hoc scripts.

Git as source

Edit the Git-native collection with the API code, run it in CI, and synchronize the accepted version to Postman Cloud after merge. Postman’s Native Git documentation describes a Local View to Git to Cloud View workflow for this model.

API specification as source

Generate the collection from OpenAPI, then add or preserve Postman-specific tests deliberately. Regeneration needs a merge strategy so it does not silently erase scripts, examples, or descriptions maintained in the collection.

Do not make Git, Postman Cloud, and an OpenAPI file equal writers with no precedence rule. The files will drift, and nobody will know which change should win.

Turn a collection into API documentation

Postman collections can store request descriptions and saved examples, but a complete API documentation set also needs authentication guidance, an error model, versioning, rate limits, webhook behavior, and task-oriented guides.

When converting a collection to documentation:

1. preserve the method, URL, headers, parameters, body, and examples;
2. identify values that came from an environment rather than the contract;
3. add the authorization and business rules that requests cannot express;
4. document errors and retry behavior;
5. validate the result against the implemented API or authoritative specification.

See the complete API documentation example for a reference page with authentication, errors, idempotency, and pagination.

DocuWriter can generate API documentation as one part of complete codebase documentation. Teams can connect repositories and generate architecture, modules, services, classes, functions, dependencies, APIs, diagrams, READMEs, and other technical components, then manage the result in Spaces and use Autopilot to help keep it current.

Export Postman collection checklist

Before sharing or committing a collection export, confirm that:

• the filename and internal collection name identify the API;
• the declared collection format is supported by downstream tools;
• required environments were exported separately or replaced by examples;
• tokens, passwords, cookies, personal data, and real responses were removed;
• scripts and outbound hosts were reviewed;
• the collection imports or runs successfully in the stated environment;
• the source of truth and synchronization direction are documented;
• generated API documentation includes rules the collection cannot express.

To export Postman collection data safely, treat the file as executable source: inspect it, remove secrets, validate its identity, run it against a controlled environment, and review every change before it reaches a shared repository.