What you can export from Postman, and what stays behind
If you are facing a Postman renewal, a plan change, or an exit decision, the first question is what you can actually take with you. Collections and environments export as JSON files: a single collection through the collection's View more actions menu, then More, then Export collection, and an environment from the Environments view. For everything at once, the bulk export sits under Settings, Account settings, Export Data, and covers collections, environments or both across personal, private, team and public workspaces. On a team plan, only Admins and Super Admins can start that bulk export, so confirm who holds that role before you plan the exit. The download arrives as an email link that expires after two days, so save the file the moment it lands.
The JSON files are the main interchange path, and they carry requests, folders, variables and most test scripts. What does not travel cleanly is Postman-specific script behavior: calls to the pm object work in some importers, while packages such as postman-collection and newman need rewriting or replacing. Cloud-only features such as shared workspace links, team roles, monitors and mock servers stay in Postman and must be rebuilt or replaced elsewhere. Scripted exports through the Postman API also count against call limits, which the pricing page sets by plan, so a large migration done by script should be sized against that allowance. Check the exported files against a sample of your most important requests before you cancel anything.
Treat the export as a working copy, not a finished migration. Store the files under version control, remove any API keys or tokens that were saved as plain values in collections or environments, and keep a dated record of what you exported and from which workspace. Ask your Postman account owner whether any workspace content sits outside the bulk export scope, and confirm the export format each target client accepts before you choose one. Bruno and Hoppscotch both document Postman import paths, so the next step depends on whether your team wants files in Git or a self-hosted shared instance.
Which Postman data exports, by method, format and limit
This table compares the three ways data leaves Postman: single collections, single environments and the account-wide bulk export. It shows the format, the access rule and the expiry for each, so you can plan an export before a renewal or plan change. Read the rows as a checklist: the bulk export is the one most likely to need an admin.
| Export method | What it covers and format | Who can run it and limits |
|---|---|---|
| Single collection | One collection saved as a JSON file via View more actions, More, Export collection | Any user who can view the collection; no bulk limit applies |
| Single environment | One environment exported from the Environments view as a JSON file | Any user who can view the environment; no bulk limit applies |
| Account-wide bulk export | Collections, environments or both from personal, private, team and public workspaces, delivered as a download link in email | Found under Settings, Account settings, Export Data; on teams only Admins and Super Admins can request it |
| Bulk download link | The email link is valid for two days after it is sent | Download promptly; request a new export if the link has expired |
| Scripted export via Postman API | Collections and environments retrieved programmatically | Calls capped at 10,000 on Free, 100,000 on Solo, 1 million on Team and 10 million on Enterprise |
| Plan-based access check | Confirm your plan and role before starting the export | Ask your Postman admin which plan and role apply to each account |
What does not export cleanly and how to work around it
Collection JSON carries requests, tests and variables, but several things stay behind or need rework: scripts that depend on Postman packages, cloud-side sharing and roles, and secret values. Each card below names one gap and a practical way to close it before you cut over.
Scripts that rely on Postman packages
Bruno translates common script APIs such as pm.test, pm.environment and pm.response during import, but it flags Postman-specific packages such as postman-collection and newman as unsupported. Any pre-request or test script that requires those packages will not run as written. Search exported collections for require( before migration, list every flagged item, and review each script by hand. Confirm the exact translation coverage against Bruno's converter documentation for your collections.
Cloud-only sharing and workspace roles
A collection JSON file does not carry Postman workspace roles, team membership, sharing links or who can edit what. Those settings live in Postman's cloud and must be recreated elsewhere. Record the current owners, editors and viewers from each team workspace before you export. In Git-based workflows, express access through repository permissions, branch protection and code review, and confirm the mapping with your own identity administrator.
Secrets in environment values
Environment exports can contain API keys, tokens and passwords stored as values, and secret-type variables may be exported differently from plain ones. Do not commit those files to Git. Move each secret into a dedicated store such as a secrets manager or your CI platform's secret settings, then reference it by variable name. Check each exported environment file for credential values before it reaches a shared folder or repository.
Vault contents and local-only data
Postman's local and shared vaults hold values that a plain collection export does not reliably move. Treat vault contents as a separate inventory. Export or copy each value through a controlled process, then store it in your chosen secret manager with an owner and rotation date. Confirm with Postman for your account exactly which vault items are included in an export and which must be copied by hand.
Request history, monitors and run data
Request history, monitor results, and past run reports are operational records rather than collection content, and they are not part of a collection export. If your audit or incident process depends on them, capture the relevant results before cancelling your plan. Ask Postman which account-level records are retained after a plan change and for how long, and decide where your organization will keep any records it must retain.
Mock servers and integrations
Mock servers, monitors and integrations configured in Postman's cloud are tied to its hosted services and do not move with the collection file. Inventory each mock URL and scheduled monitor that other teams call. Rebuild the ones you still need on infrastructure you control, and update base URLs in dependent pipelines and documentation so no consumer breaks at cutover.
How to run a complete Postman export in order
This sequence gets every collection and environment out of Postman, checks the copies against the source, and parks the archive somewhere your organization controls before any account change or plan downgrade takes effect.
Inventory workspaces, collections and environments
Before exporting anything, list every workspace you can see, including personal, private, team and public workspaces, and record the collections and environments in each. Note the owner of each workspace and which items are shared with teammates. Keep this list as a baseline, because the verification step later depends on it. The step is done when you have a written inventory with one row per collection and one row per environment, and each row names its workspace.
Request the bulk export as a team Admin
In Postman, open Settings, then Account settings, then Export Data, and choose collections, environments or both. On a team, only an Admin or Super Admin can run this export, so anyone else must ask one to start it. Postman delivers the result as an email download link that expires after two days, so request it early and tell the person who receives the email to download it immediately. The step is done when the download link has arrived and the archive is saved.
Export single collections and environments as a fallback
If the bulk export is unavailable, incomplete or late, export each collection from its View more actions menu, then More, then Export collection, and export each environment from the Environments view. Each collection saves as a JSON file, which is the format Bruno and Hoppscotch can import. Name the files with the workspace and version so they are easy to match against your inventory. The step is done when every inventory row has a matching file.
Script API exports within your plan's call limit
If you have many collections or need repeatable exports, script calls to the Postman API. Postman's pricing page limits API calls to 10,000 on Free, 100,000 on Solo, 1 million on Team and 10 million on Enterprise, so check your plan before starting and count the calls your script will make, including one per collection listing and one per export. Run the script with a key scoped to the accounts that need it, and log each request and response status. The step is done when the script has run to completion and the log shows no failed calls.
Verify the export against the source
Compare each exported file with the baseline inventory. Check that the number of collections and environments matches, that each collection's request count matches what Postman shows in the collection, and that every environment's variable names match the source. Variable values may legitimately differ in secret fields, so confirm names and scope rather than values where secrets are masked. Record any mismatch and re-export that item. The step is done when every row in the inventory is marked as matched or explained.
Store the archive in controlled storage
Move the verified export files to storage your organization controls, such as an approved file share, an encrypted object store or a Git repository with access controls. Environment files may contain credentials, so restrict who can read them and keep them out of shared or public repositories. Record where the archive lives, who has access and the date it was taken. The step is done when the archive is in that location, access is limited to named people, and the record is written down.
How the exported JSON feeds Bruno and Hoppscotch
The export you take from Postman is only useful if the destination can read it, and the common language here is the Postman Collection v2 or v2.1 JSON format. Bruno imports collections exported in either format, so a per-collection JSON file from the export steps can go straight into Bruno's Postman migration path. Bulk import of a full Postman data dump, covering all collections and environments in one go, is a feature of the paid Bruno Ultimate edition, so a team that wants that single-step import should confirm the edition it needs before it starts. Bruno also translates common script calls such as pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response during import, and it flags Postman-specific packages such as postman-collection and newman as unsupported. Review every flagged script by hand, because those are the lines that will fail silently in CI if they are left unchanged.
Hoppscotch takes the same JSON through its importer, which accepts collections and environments from Postman and Insomnia. The limit that matters for planning is the import size: the importer documentation sets 10 MB on Hoppscotch Cloud and 50 MB on self-hosted editions. Check the size of your largest exported file, especially collections that embed large response bodies or file uploads, before you schedule the import on a self-hosted instance. Environments import separately from collections, so confirm that secret values are present in the export and that the Hoppscotch environments are populated after import.
Neither import is guaranteed to be complete, so keep the OpenAPI specification as a second source. Both Bruno's bru import command and Hoppscotch's importer can build collections from an OpenAPI document, which helps when a Postman collection is missing requests, examples or documentation that the API's own specification describes. Compare the two outputs request by request before you retire the Postman workspace, and record any gaps in your migration notes. Keep the original export files under version control or in an approved archive for the period your records policy requires, since the Postman download link expires after two days and cannot be used as a long-term copy.
Questions buyers ask before exporting Postman data
How much effort does exporting Postman data take, and what drives it?
The effort depends mainly on how many collections and environments you have, how many workspaces they sit in, and whether scripts and test assertions must survive the move. A single collection exported from the collection menu is a short task. A full account export is a different job, because it needs an admin, a download window and a review of each collection afterward. Scripts add work only if you plan to run them in another client, since they often need rewriting. Ask your team to inventory collections by workspace and flag any that use custom scripts before estimating time with any vendor.
Can a non-admin user run the Postman bulk export?
On Postman teams, no. Only Admins and Super Admins can export bulk data, so a regular member must ask an admin to run the export or export collections one at a time. Individual collections and environments can be exported by anyone with access to them through the collection and environment menus. Before you plan the work, confirm the current role names and permissions for your plan with Postman, since team roles can change between plan versions.
What should we do if the bulk export download link expires?
Postman delivers the bulk export as an email download link that expires after two days, so an unread or forgotten email can waste the window. Start the export only when someone can download and store the file the same day, and keep the file in a controlled location with restricted access, because it can contain credentials stored in collections and environments. If the link expires, request a new export from an admin. Confirm with Postman how many exports an account can request, since that is not covered by the researched facts.
Can the Postman API automate exports, and what do the call limits mean?
The Postman API can read collections and environments in scripts, but every call counts against a monthly limit that depends on your plan. Postman's pricing page lists 10,000 calls on Free, 100,000 on Solo, 1 million on Team and 10 million on Enterprise, so a large account with many collections may reach a lower tier's limit quickly. Estimate the number of requests your export script needs, including one per collection plus any environment calls, and compare it with your plan limit. Confirm with Postman whether bulk export calls count in the same way.
Do Postman scripts convert automatically when we move to Bruno?
Bruno translates common Postman script APIs during import, including pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response. It flags Postman-specific packages such as postman-collection and newman as unsupported, so those scripts need manual work. Expect a review pass after import, and run the converted collections against a live target before you retire the Postman copies. Hoppscotch's importer handles collections and environments but scripts still need rewriting, so check each vendor's documentation for the exact script behavior you rely on.
Should we hire outside help for the Postman export and migration?
Outside help makes sense when collection volume is high, when scripts depend on Postman-only packages, or when the team lacks time for testing. DeployOpen plans and implements self-hosted open-source platforms in the client's own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A written scope is the basis for any quote. DeployOpen does not publish a price list, so ask for a scoped proposal that lists the collections, scripts, workspaces and the target client in your environment.
What should we ask Postman and the target vendor before we start?
Ask Postman which roles can run bulk export on your plan, how many export requests are allowed in a period, and whether API calls for export count toward your monthly limit. Ask Bruno which import features need a paid edition, since bulk import of a full Postman data dump is included in Bruno Ultimate Edition, and ask Hoppscotch whether your self-hosted import size fits its documented limit. Confirm these answers in writing before you schedule the export, so the timing matches the team's availability.
What to plan before the Postman contract ends
Export is the last step of a larger decision, so the choices below should be settled in roughly this order. Each card is a question to resolve with your own contract dates, seat counts and security requirements, not a fixed schedule. Answering them early leaves time to test the exported collections before access ends.
Confirm plan and seat details
Start with Postman's About plans documentation and your current order form. Confirm which plan each user sits on, how many seats are paid, and whether any user relies on features that only a higher plan includes. Note who holds the Admin or Super Admin role, because only those roles can run a bulk export on a team. Record the renewal or end date in writing so the export plan has a fixed reference point.
Set the export window before renewal
A bulk export is delivered as an email download link that expires after two days, so the request needs a named owner who can act within that window. Ask who will receive the email, whether that mailbox is monitored, and whether the download can be completed during working hours. Plan for a second request if the first link expires before the archive is saved.
Choose the target client
Decide between Bruno, where collections are plain files that live in Git, and a self-hosted Hoppscotch Community Edition, where team workspaces sit in your PostgreSQL database. Bruno suits teams that already review code in Git. Hoppscotch suits teams that want a shared web workspace on their own servers. Test a sample collection in the target before committing to it.
Decide whether SSO and SCIM are required
Identify whether your identity policy requires SAML single sign-on or SCIM user provisioning for the API client. Hoppscotch Community Edition signs users in through Email, GitHub, Google and Microsoft OAuth providers, while SAML and SCIM sit in its Enterprise Edition. Bruno's SAML SSO and SCIM provisioning are tied to its paid editions. Ask each vendor to confirm current licensing for your exact requirement before you budget for it.
Plan the Postman API quota for scripted exports
If you plan to script exports through the Postman API instead of using the console, check the monthly call limit for your plan on Postman's pricing page. Large workspaces with many collections and environments can use calls quickly, so estimate the number of requests before starting. A scripted export also needs an API key owned by someone with the right access, which should be rotated or revoked once the migration ends.
Plan retention and deletion of archives
Exported JSON files contain request URLs, headers, scripts and sometimes credentials or tokens, so treat them as sensitive. Decide where the archive is stored, who can read it, how long it is kept, and when it is securely deleted after the migrated collections are verified. Confirm that your data retention policy covers the exported copies, and remove any stored secrets before they reach Git.
What each team needs to do during the export
On Postman teams, only Admins and Super Admins can run the bulk export from Settings, Account settings, Export Data. Anyone else on the team will need an admin to start it, so confirm early who holds that role and who will be available when the download link arrives by email. The bulk export covers collections, environments or both, drawn from personal, private, team and public workspaces, and the download link expires two days after it is sent.
- Confirm the role holder: Check that at least one Admin or Super Admin is reachable during the export window.
- Choose the scope: Decide whether the archive covers collections, environments or both, and which workspaces must be included.
- Watch the two-day window: Download the archive as soon as the email arrives, because the link expires after two days.
- Use per-collection exports for gaps: Export individual collections as JSON from the collection menu if a workspace is not covered by the team's request.
- Record the request: Note who asked for the export, when it was requested and where the file was delivered.
Before the request, confirm the admin has permission to move the archive off Postman's servers under your internal policy.
Engineers verify that the exported files are complete and then convert them into the target client. Postman exports use Collection v2 or v2.1 JSON, and Bruno imports those formats, while Hoppscotch's importer accepts Postman collections and environments. Plan a test import on a copy of the data first, and compare request counts, folder structure, variables and test scripts against the original collections in Postman.
- Check file completeness: Compare the number of collections and environments in the export with the count visible in Postman.
- Review scripts: Bruno translates common Postman script APIs such as pm.test and pm.environment, but flags packages such as postman-collection and newman as unsupported, so list every script that needs rewriting.
- Test the import: Run one collection through Bruno or Hoppscotch and send real requests to a non-production endpoint.
- Size large imports: Check the Hoppscotch import limit, which is 50 MB on self-hosted editions, against the size of the exported files.
- Use the API for scripted pulls: If you export through the Postman API, remember that call limits apply to the plan, from 10,000 calls on Free to 10 million on Enterprise.
Confirm with the client vendor which edition covers the bulk import you need before you plan the cutover.
Security and compliance staff decide where the archive is stored, who can open it and how long copies remain. A Postman export can contain collections with embedded credentials, tokens and internal hostnames, so the archive is sensitive data in its own right. Set storage rules before the download starts, and make sure the copy is handled the same way as other source code or configuration data.
- Classify the archive: Treat exported collections and environments as potentially containing secrets, and label them accordingly.
- Choose the storage location: Keep the archive on infrastructure your organization controls, such as an encrypted file share or a repository with access control.
- Restrict access: Limit who can open the files to the migration team and remove access once the import is verified.
- Scrub and rotate: Find credentials in exported environments, move them to a secrets manager and rotate any value that was shared in a collection.
- Set a deletion date: Record when the source archives and any local copies will be deleted, and document the decision.
Ask your legal and data protection contacts whether any residency commitments apply to the archive before it is stored outside the cloud account where Postman data was held.
What leaves Postman and how
Start by deciding whether you need one collection or the whole account, because Postman offers two different export paths. For a single collection, open the collection's View more actions menu, choose More, then Export collection. Postman saves it as a JSON file. Environments are a separate export from the Environments view, so a collection file alone does not carry the variables its requests depend on. Before you store any environment file, confirm whether secret values are included in the export, because an environment file can hold tokens and keys that would then sit in a folder, a ticket or a Git repository. Treat every export as sensitive material until you have checked it.
For the whole account, use Settings, Account settings, Export Data. It can export collections, environments or both, and it draws from personal, private, team and public workspaces. Postman sends the result as an email link that expires after two days, so the window to download the archive and copy it to storage you control is short. On team plans only Admins and Super Admins can request a bulk export, so confirm who holds those roles before you set a migration date. An engineer who owns a workspace but lacks an admin role will need someone else to start the export, a step that is easy to miss in planning.
Scripted exports through the Postman API are capped by plan: 10,000 calls on Free, 100,000 on Solo, 1 million on Team and 10 million on Enterprise. A script that fetches each collection and environment individually consumes calls, so estimate the count from your workspace inventory before you run it, and check the current limits on Postman's pricing page when you plan. Whichever route you use, verify the result by comparing the number of collections and environments in the files against what Postman shows. Store a checksum and a short manifest alongside the files, because that record is what lets a reviewer confirm the export was complete.
How DeployOpen works on this
DeployOpen plans and implements the move off Postman inside your own infrastructure, so collections, environments and test data are exported, checked and stored where your team controls them. Work starts from a written scope that names the workspaces, collections and pipelines in play.
How we scope
- Inventory which personal, private, team and public workspaces hold collections and environments that must leave Postman.
- Identify who holds Admin or Super Admin rights needed for a bulk export, and confirm the timing of that request.
- Record which scripts, CI jobs and API call volumes depend on Postman, so exports through the Postman API are planned within its limits.
How we build
- Export each collection and environment as JSON and keep the files in a version-controlled repository on your own servers.
- Run the Postman Collection v2 or v2.1 files through the Bruno or Hoppscotch importer and log every script or package it flags.
- Test imported collections against the live APIs and compare responses with those from Postman before retiring any collection.
How we hand over
- Deliver a written record of each exported item, its source workspace, its target location and who verified it.
- Document where secrets and tokens now live, and confirm that no credential remains in exported files committed to Git.
- Provide runbooks for the team, covering the download window, re-export steps and how to add new collections after cutover.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades of your self-hosted Hoppscotch or Bruno tooling, and continuous testing are available as a retainer.
- Ask for a quote that itemizes export effort, import and script rework, documentation and any retainer, based on the written scope.
