How to export your data from Insomnia

How to export your data from Insomnia before you leave

Insomnia lets you take your data out as collections, projects or all data exported as Insomnia v5 YAML or HAR, and as OpenAPI specifications generated with the inso CLI. Which of these you get depends on where each project is stored. A local project can be exported directly from the app, Git Sync projects already keep their files in your repository, and Cloud Sync projects are only as complete as what the app can reach in Kong's cloud. Before a renewal or a data residency review, ask Kong in writing which items each export includes and excludes, because exports may not carry every setting, plugin configuration or secret reference.

Choose the format by where the work goes next. Insomnia v5 YAML is the most complete copy of requests, folders and environments for moving into another client, and it is the file to take into a migration, which the Bruno migration page covers step by step. HAR is a record of network traffic. It helps when you need to share a reproduction of a failing request or review what was sent, but it is not a collection format, so treat it as evidence and keep a separate collection export as your backup. When the team needs the API description itself, the inso CLI can generate an OpenAPI specification from a project, which suits a service catalog or an import into Hoppscotch or Bruno. Run one export of each type against a copy of a project and open the results before you rely on any of them.

Check for secrets before any file leaves the app or your repository. Environment variables, authorization headers, API keys and OAuth tokens may appear in exports, and HAR files often capture headers and cookies from live responses. Search each export for token strings and client secrets, rotate anything that appears in a file shared outside the team, and store exports in an access-controlled location with the same rules you apply to other credentials. For Git Sync projects, the repository history is effectively the export, so scan it for committed secrets before you grant anyone access to a new host. For Cloud Sync projects, export and verify a full copy before you remove the project, and confirm with Kong how long cloud copies stay accessible after any change to your plan.

Which Insomnia data you can export and how

This table lists each type of Insomnia data, the route to export it, the file format and what to confirm before you rely on the file. Use the Format column to plan which file a Bruno or Hoppscotch import will need, and treat the last column as a pre-export checklist. The main takeaway is that Git Sync projects already sit in files outside Insomnia, while Cloud Sync data needs an explicit export before any plan change.

Data	Export method	Format	Confirm before you start
Collections	Export from within the app, one collection at a time	Insomnia v5 YAML or HAR	Whether environments and scripts are included in each format
Projects	Export the whole project from within the app	Insomnia v5 YAML	Whether one file holds every collection in the project
Environments	Included when you export the collection or project that uses them	Insomnia v5 YAML	Whether secret values are included in the file
OpenAPI specifications	Export the design document with the inso CLI	OpenAPI via inso	The inso version and command syntax your install supports
Git Sync projects	Clone the repository directly with Git, outside the app	Files in the Git repository	What the repository holds and who has read access to it
Cloud Sync projects	Export from within the app while signed in, before retiring the project	Insomnia v5 YAML or HAR	That export is available on your plan and covers all requests
Secrets and credentials	Review each exported file before sharing or importing	Text review of YAML or HAR	Tokens, passwords and API keys in headers, auth and environments
Size and export limits	Not stated here	Varies by format	Current limits in Kong's Insomnia export documentation

Choosing the export format for each destination

Insomnia can produce several export formats, and each keeps a different part of your work. Choose the format by the destination you need, then check what it leaves behind before you depend on it. The cards below cover the formats and checks that most migrations need.

Insomnia v5 YAML for re-import

Use Insomnia v5 YAML when the file must return to a client or live in version control. It suits moving collections into Bruno or another client because it keeps requests, folders and environments in a text form that diffs cleanly. Confirm which settings carry over, such as authentication details and plugin data, since app-specific metadata may not survive. Run a sample import into the target client before exporting everything.

HAR for captured traffic

A HAR file records request and response pairs from a live session, including headers, timings and bodies. It fits debugging, support tickets and proof of a specific call. A HAR file does not hold a collection, so expect no folder structure, scripts or reusable environments. Because HAR files often contain cookies, bearer tokens and personal data in plain text, review every HAR file before it leaves your network.

OpenAPI for specs and contract tests

Export OpenAPI when the goal is a specification that drives contract tests, documentation or code generation. The inso CLI can produce the spec from an Insomnia project. Expect paths, methods, parameters and schemas to carry over, but scripts, environment-specific values and request chaining to stay behind. Validate the output with your own linter, then test it in the target tool, such as the Hoppscotch importer, which accepts OpenAPI collections.

Plain Git repositories for Git Sync

Git Sync projects already keep their files in a repository you control, so the cleanest export is the repository itself. Confirm the remote holds the latest branches and commits and that no local changes sit unpushed. Check whether the repository contains environment files or credentials, because any secret committed there reaches every clone. This route skips a conversion step, so the files stay in their original structure.

Secrets check before export

Every format can carry credentials, including API keys in environments, bearer tokens in auth settings and values inside scripts. Search each export for these values before it leaves the app. Rotate any key that has appeared in a shared or cloud-synced file. Store exports where your security policy applies, and limit access to the people who need the collection.

Export paths for local, Git Sync and Cloud Sync projects

Local projects exist only in the Insomnia app on a specific machine, so the export is the only copy you can move. Export the collection, its environments and any scripts before you uninstall the app, reset the workspace or replace the laptop. Insomnia's export options let you take out a single collection or project, or all data at once, in its Insomnia v5 YAML or HAR format. Confirm the exact menu path and format options in the version you run, because the export screens have changed across releases.

Export each project separately: Use one export per collection so a later import into another client is easier to check.
Include environments and scripts: Variables and pre-request or test scripts often live outside the request list, so confirm they appear in the file.
Record where secrets sit: Local Vault values may be stored in the app and may not travel with a plain export. Check before you assume credentials moved.
Keep a dated copy: Store the export in a location your team controls, such as a repository or an approved file share.
Verify by re-opening: Import the export into a scratch workspace and compare request counts and environment names.

Before you delete a local project, confirm the export opens cleanly and contains every request your team relies on.

Checking secrets before export files leave the app

Exported Insomnia files can carry credentials that travel with them: API keys, bearer tokens, basic auth passwords and environment values such as base URLs or client secrets. Unless you remove them, a YAML, JSON or HAR file hands those values to anyone who opens it, including a new client, a Git repository or an email attachment. Treat every export as sensitive until it has been reviewed, and decide before you export which environments and authentication settings the target client actually needs.

Run a review step on each file before it leaves your controlled storage. Search the exported YAML, JSON and HAR files for credential fields such as apiKey, bearerToken, password, secret and Authorization headers, and check environment sections for live hostnames or tokens. HAR files deserve extra attention because they can also capture request and response headers and bodies from earlier sends. Then move each real value into the target client's own vault or environment store, leaving placeholders in the shared file. Confirm the exact field names in your export by inspecting a test file, since they depend on the Insomnia version and auth type.

Limit who can open the export. Store it in a restricted location, share it only with the people migrating the collection, and delete working copies once the import is verified. Do not assume that Insomnia's Local Vault protects the exported file, because the export is a separate artifact. Ask Kong, in writing, what the Local Vault encrypts and whether an export includes encrypted or plain values. If you plan to commit the collection to Git, confirm that the placeholder version is the only one tracked and check the history for earlier commits that contain secrets.

The sequence for a complete Insomnia export

This sequence turns a scattered set of Insomnia workspaces, projects and storage types into a verified export set that a target client can read and a team can archive. Each step ends with a check, so nothing leaves Insomnia unverified.

Inventory every workspace, project and storage type
List each workspace and project in Insomnia, and record where each one is stored: local scratch data, a Local Vault project, a Git Sync project, or a Cloud Sync project. Note the owner of each item and whether it is still used. The person running the export, usually an API platform lead, owns this list. It is complete when every item on the list has a storage type and an owner, and the team lead has confirmed that nothing is missing.
Export each item in the chosen format
For each inventory item, export it from Insomnia in the format you agreed for the target client, such as Insomnia v5 YAML or HAR for collections and projects, and export OpenAPI specifications with the inso CLI where the design lives in a spec. Name each file with the workspace name and the export date. Confirm the export location is an encrypted disk or approved share, not a personal download folder. The output is one file per item in a named folder, with a row in the inventory marked as exported.
Run the secret check before any file moves
Open each exported file in a text editor and search for tokens, passwords, API keys, bearer strings, client secrets and cookies, including values stored in environments and auth settings. Replace real secrets with variable references or remove them, and confirm that the source project still works with its own stored values. A security engineer or the project owner signs off on this step. The output is a short log per file that lists what was found, what was removed, and who checked it.
Import into a test instance of the target client
Create a separate test instance of Bruno or Hoppscotch, using a non-production workspace or a local install, and import the cleaned files. For Hoppscotch self-hosted, confirm the file is under the 50 MB self-hosted import limit before importing. Watch the import log for skipped or unsupported items, such as Postman-specific packages or scripts that did not translate. The output is a test collection with a written list of every warning the importer produced.
Compare requests, environments and auth settings
Compare the test import with the source workspace item by item. Count the requests in each folder, check every environment variable and its scope, and confirm each auth method, such as bearer, OAuth 2 or API key, is set on the same requests or folders. Send a sample of requests from both clients to the same non-production endpoint and compare the responses. The reviewer is the API owner, who signs off that counts and behavior match. The output is a comparison sheet with zero open differences, or with each difference listed and accepted in writing.
Run the migrated tests from the command line
If the collection contains tests, run them once from the target client's command line tool, such as bru run for Bruno or hopp test for Hoppscotch, and save the report. Compare the pass and fail results with the results from Insomnia for the same requests. Investigate any difference before continuing. The output is a saved test report from the target client stored with the comparison sheet.
Archive source files and record sign-off
Store the exported files, the secret check log, the import warnings, the comparison sheet and the test report in a single controlled archive with access limited to the people who need it. Record the sign-off of the API owner and security reviewer on a one-page record, and list the Insomnia items that are approved for retirement. Ask your procurement or administration team to confirm the retention rule for these files, since your policy decides how long they are kept. The output is a signed archive index that lets an auditor trace each collection from source to target.

What does not export and the workaround for each gap

A standard export carries requests, folders, environments and scripts, but several items sit outside the collection file. The five cards below cover the categories most likely to be missing. Confirm each behavior with Kong before you rely on an export, and rebuild anything absent in the target client.

Account-level settings

Personal preferences, appearance, keyboard shortcuts and organization-wide defaults usually live in your Insomnia account or app profile, not in the collection files. Assume these settings will not export. Before you cancel, note each setting your team relies on, such as default environments, proxy and certificate options, and request timeouts. Ask Kong which of these, if any, appear in an export, then recreate the rest by hand in Bruno or Hoppscotch.

Team membership and roles

An export contains request data, not the list of people who belong to your organization, the roles they hold or the projects they can open. Membership has to be rebuilt, not moved. Ask Kong whether the member list and role assignments can be exported, and keep a copy while your plan is active. In the target, Bruno's paid editions cover SAML single sign-on and SCIM provisioning, and Hoppscotch Enterprise adds SCIM user and group provisioning, so your identity provider can drive access instead of manual invitations.

Cloud Sync history

Cloud Sync projects keep their change history on the vendor side, and a file export captures only the current state of each collection. Past versions may stay with Kong. Ask whether earlier versions, comments or branch state can be retrieved after you leave the service. Export each project with a dated file before you stop sync. If a project already used Git Sync, its history lives in your repository, so confirm which projects fall into each case.

Plugin and scripting state

Request scripts usually travel with their requests, but plugin installations, plugin settings and any data a plugin stores do not carry over to another client. Plugin behavior needs a manual check. List every plugin your team uses, then run each request that depended on one. Hoppscotch's importer accepts Insomnia collections, so verify how scripts arrive. Bruno's documented script translation covers Postman APIs, so review any script that relied on Insomnia-specific helpers before you trust its test results.

Encrypted credentials and secrets

Tokens, client secrets and certificates kept in an encrypted vault may not export in readable form, and an encrypted file is of little use without the key that protects it. Treat every secret as lost until you confirm it exported. Check each request for embedded credentials before export, and ask Kong how vault values are handled. Re-enter secrets in the target client's environment or secret store, and rotate any credential you cannot account for. Self-hosted Hoppscotch and offline Bruno keep what you enter on infrastructure you control.

What to plan before the Insomnia contract renews or ends

Exporting is the easy part. The risk sits in the decisions around it: who runs the export, what happens to Cloud Sync while data is moving, which seats are retired, and when access ends. Settle these before the renewal or termination date so the export is complete and the old access closes cleanly.

Set the export window and owner

Name one person who owns the export and a backup contact, and agree on a window that ends before the contract's access cutoff. Each project and collection should be exported and checked by someone who knows what it contains. Confirm the notice period and the termination terms in the written agreement with Kong, since those dates decide how much time you have.

Freeze Cloud Sync changes

Ask the team to stop editing Cloud Sync projects once the export starts, or the exported files will not match what people see in the app. Record which projects use Cloud Sync, Git Sync or the local vault, because each one stores data in a different place and needs its own export step. Keep the freeze until every project has been exported and verified.

List users and seats to retire

Build a list of every member, guest and service account with access to Insomnia projects, including people who have left. Match each seat to the projects it can open, so you know who needs the export and who only needs access removed. Seat counts drive the cost of running both tools in parallel, so this list also shows how many paid seats can end on the same date.

Plan the access revocation date

Choose the date when Insomnia access ends for each user, and remove shared project access before the account itself is closed. Confirm with Kong how long your data remains available after termination and when it is deleted. Check whether any collections depend on a shared account or an API key, since those credentials must be rotated before the old access stops.

Set retention rules for exported files

Exported YAML, HAR and OpenAPI files can contain URLs, headers, tokens and sample bodies. Decide where they are stored, who can open them, how long they are kept and how they are deleted. Run a secrets check before any file leaves the app, and keep the export location on infrastructure your organization controls.

Test the target client before cutover

Import a sample of exported collections into the target client and run them, including authentication, environments and scripts. Compare the results with the same requests in Insomnia. Flag any Postman-specific or Insomnia-specific script behavior that the importer does not translate, and run the collections from the command line if your CI depends on them.

What teams ask before exporting from Insomnia

How much effort does a full Insomnia export take?

Effort depends mostly on how much you have built up in Insomnia, not on the export itself. The export is a file operation, but each project, environment, script and authentication setting must be checked after it lands in the new tool. Teams with a handful of collections and few scripts usually finish quickly. Effort rises with the number of projects, the number of environments per project, custom pre-request and test scripts, and how many projects sync through Cloud Sync or Git Sync. Count these before you start, because they set the work list. Ask any partner to base the quote on that inventory.

Can our team export Insomnia data without outside help?

In many cases yes. Insomnia can export collections, projects or all data as Insomnia v5 YAML or HAR, and the inso CLI can produce OpenAPI specs, so the mechanics are within reach of an in-house engineer. Outside help becomes useful when the collection set is large, when scripts depend on secrets or internal services, or when you need a repeatable process across many teams. DeployOpen plans, implements and documents this kind of work inside your own infrastructure under a written, fixed scope, so you can choose between doing it internally and buying the work.

What sets the timeline for moving data out of Insomnia?

The timeline is set by the inventory and by the target tool's readiness, not by the export button. The main drivers are the number of projects and their sync type, how many scripts need rewriting, whether environments hold credentials that must be moved through a secure channel, and whether the new instance is ready for users. Hoppscotch's importer also has a 50 MB limit on self-hosted editions, so very large exports may need splitting. Ask for a schedule that lists each phase and its dependencies, and confirm which steps depend on your team's availability.

What must our team provide before an export starts?

Three things make the work predictable. First, administrative access to the Insomnia organization, including the ability to see every project, Cloud Sync and Git Sync configuration, and team membership. Second, a written inventory of projects, environments, scripts, authentication methods and the people who own each collection. Third, a test environment, either a non-production Bruno folder or a Hoppscotch instance inside your network, where imported collections can be run before anyone relies on them. Confirm with your security team who may receive exported files and where they may be stored.

Can exported Insomnia files be imported into Bruno or Hoppscotch?

Both targets have documented import paths, but the result needs review. Bruno's guide describes a route from Postman, and Bruno's Migrating from Postman documentation covers Collection v2 and v2.1 JSON, which is the common interchange format. Hoppscotch's importer accepts collections and environments from Insomnia directly, subject to its size limits. Neither import is a guaranteed one-to-one copy. Check request order, variable names, authentication and scripts after each import, and run the collection against a test server before retiring the original. Ask the implementer which fields were tested in your collections.

How should we handle secrets before files leave Insomnia?

Assume that exported files may contain credentials until you have checked them. Environments, authentication headers and scripts can carry tokens, API keys and passwords, so review each export before it is copied to a laptop, a Git repository or a shared drive. Store secrets in your own secrets manager or in local variables, not in committed files. Keep exports in a location your security policy allows, and delete temporary copies once the import is verified. Ask your partner to document the redaction and handling steps as part of the deliverables.

What should a quote for an Insomnia export include?

A useful quote lists the scope in writing, not a total on its own. It should name the projects and environments in scope, the export formats and tools used, the target platform (Bruno, a self-hosted Hoppscotch instance or both), and how scripts, authentication and secrets are handled. It should state the deliverables, such as converted collections, a verification log, a runbook and a retirement checklist for Cloud Sync projects. It should also say what is excluded, who performs testing and what your team must supply. For any cost you compare, ask which parts are one-time and which recur, such as hosting, upgrades and support.

How DeployOpen works on this

DeployOpen treats an Insomnia export as a scoped piece of migration work, not a file download. We agree in writing which projects, Cloud Sync and Git Sync workspaces, environments and secrets are in scope, then deliver the exported files with a checked inventory of what was and was not taken out.

How we scope

Inventory every Insomnia project, including Cloud Sync and Git Sync projects, and record where each one lives.
Agree in writing which export formats are needed, such as Insomnia v5 YAML, HAR or OpenAPI specs from the inso CLI.
Confirm with you who decides which environments and credentials are excluded before any file leaves the app.

How we build

Run the exports on a controlled workstation and keep a log of each file, project and export date.
Scan exported files for embedded tokens, API keys and passwords, and redact or remove them before handover.
Test a sample import into the target client, such as Bruno or a self-hosted Hoppscotch instance, to confirm requests and environments load.

How we hand over

Deliver the exported files with a manifest listing projects, formats, checksums and any items left out on purpose.
Document the export steps, the secrets check and the open items your team must confirm with Kong or your own administrators.
Walk your team through the handover so the Cloud Sync or Git Sync projects can be retired on your own schedule.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after the handover is complete.
Ask for a written quote based on your scope. DeployOpen does not publish a price list.