Question
Insomnia Environment Variable Conflicts During Workspace Import
Ira Atlas
0 reputation · 28 Mar 2023, 02:48 UTC
views
Loading…
0 reputation · 28 Mar 2023, 02:48 UTC
Insomnia allows users to back up and restore request collections and environment settings using a JSON-based export format. When restoring this data via the Import Data function, the application recreates the workspace state, including environment variables and plugins.
A specific uncertainty arises when importing a JSON backup into a profile that already contains an existing workspace with the same name. The current behavior regarding how the application handles overlapping environment variable keys is not explicitly defined in the documentation.
If the imported dataset contains variables that already exist in the target environment, it is unclear whether the system merges the values, overwrites the existing keys, or creates duplicate entries.
Insomnia does not merge environment variables key-by-key on import. Import matching is by internal resource ID, not by workspace or environment name. If the imported backup contains a workspace with the same wrk_ ID as your existing workspace, the imported environment record replaces the stored one in one step. Imported values win for shared keys and any local-only keys that exist only in the current environment are dropped. If the IDs differ, Insomnia creates a duplicate workspace/environment instead of merging. There is no built-in configuration to trigger a key-level merge during Import Data.
The overwrite behavior is a consequence of the replace-by-ID model used by recent desktop releases. Name collisions without ID collisions are not deduplicated: importing a sub-environment with the same name but a different env_ ID creates two same-named environments. Only the active environment's values resolve at request time; nothing is merged.
Git Sync is the supported way to get real merge semantics. With a collection in Git, environments are stored as files and Git resolves conflicts file-by-file on pull, unlike the one-shot importer.
One detail that changes the recommendation: does the backup's workspace wrk_ ID match your current workspace's wrk_ ID? Confirming that lets us say definitively whether the import will overwrite or create a duplicate.
Use comments to ask for clarification. Post a solution as an answer.
3,160 reputation · 28 Mar 2023, 04:02 UTC
Building on the explanation of ID-based replacement, it is critical to note that because the entire environment document is swapped, any local-only variables (such as temporary API keys or secrets added after the last export) are permanently deleted during the import if the env_ IDs match.
To prevent accidental data loss during a restoration, verify the following before importing:
This behavior is consistent across recent desktop versions where the internal resource ID acts as the primary key for the data store.
insomnia