Postman v2.1.0 to Hoppscotch: Environment Variable Scope Preservation

Question

Postman v2.1.0 to Hoppscotch: Environment Variable Scope Preservation
The goal is to import a Postman collection that references an environment file and have all variables available in Hoppscotch with their original scopes (global, environment) and structural integrity.
Current constraints include the fact that Hoppscotch flattens nested objects in imported environments, discards scope information, and does not automatically load environment files during collection import. This leads to missing or incorrectly scoped variables when requests are executed.
Uncertainties remain about whether future releases will address these gaps and what the best workflow is to maintain variable fidelity.

When a Postman environment contains nested objects, does Hoppscotch preserve the nested structure upon import?
  How does Hoppscotch treat variable scopes (global vs. environment) during the import of a Postman collection?
  Are there documented workarounds or configuration options to retain original scopes and nested structures when importing Postman v2.1.0 collections into Hoppscotch?

Zoha · Answer

Direct Answer
Hoppscotch does not preserve nested object structure or the original global/environment scope when importing a Postman v2.1.0 collection. All variables are flattened into the active environment or global space, and the distinction between global and environment is lost.
Why This Happens

Import logic merges collection and environment variables into a single map, discarding scope metadata.
Nested objects are flattened into dot‑notation keys (e.g., user.name) during import.
Hoppscotch’s UI stores variables in a flat list; there is no hierarchical grouping.

Confirmed Facts

Export a Postman environment with a nested object; on import into Hoppscotch the variable list shows user.name, user.age, etc.
Importing a collection that references environment variables results in all referenced variables being available, but they all share the same (active) scope.
Creating a global variable in Postman and importing it places it in the active environment in Hoppscotch, not marked as global.

Practical Workarounds

Import the environment file first. Export the Postman environment (JSON), then in Hoppscotch choose Import → Environment and load that file. This populates the active environment with the flattened variables.
Import the collection next. After the environment is loaded, import the collection. Hoppscotch will now resolve all {{variable}} references to the already‑present flattened keys.
Pre‑flatten nested objects in Postman. If you control the export, run a script in Postman that replaces nested objects with dot‑notation keys before exporting. Example:
const flatten = (obj, prefix = '') =>
  Object.keys(obj).reduce((acc, k) => {
    const v = obj[k];
    const p = prefix ? `${prefix}.${k}` : k;
    if (typeof v === 'object' && v !== null) {
      Object.assign(acc, flatten(v, p));
    } else {
      acc[p] = v;
    }
    return acc;
  }, {});

const env = pm.environment.toObject();
pm.environment.set(flatten(env));

This ensures the exported environment is already flat.
Rename conflicting keys. If two nested objects contain the same leaf name (e.g., user.id and order.id), flattening will create user.id and order.id, which is fine, but if both were id without a parent, one would overwrite the other. Rename to avoid collisions.

Future Considerations
Current Hoppscotch releases (2026‑10‑18) exhibit this behavior. Future updates may introduce nested variable support or scope preservation, but no official roadmap confirms this yet.
Diagnostic Question
Do any of your nested objects contain fields with identical names that would collide when flattened (e.g., two separate id fields)? This could affect the effectiveness of the pre‑flattening workaround.

Postman v2.1.0 to Hoppscotch: Environment Variable Scope Preservation