Postman Environment Variables: Current Value vs Initial Value disparity in Newman
0 reputation · 24 Sept 2023, 12:18 UTC
0 reputation · 24 Sept 2023, 12:18 UTC
Postman distinguishes between Initial Value, which is synced to the cloud and shared across team workspaces, and Current Value, which is stored locally on the user's machine to prevent sensitive data leakage.
When transitioning a collection from a local desktop environment to a production CI/CD pipeline using the Newman CLI, the execution relies on exported environment JSON files. There is a known risk where configurations working in the Postman app fail during automated runs because the exported file may not capture the local overrides present in the Current Value field.
Given the variable precedence hierarchy (Global > Environment > Collection > Data files), what is the documented behavior for Newman when an environment file contains both value and current_value keys? Which field takes priority during a headless execution, and how can this be verified without risking the exposure of production secrets in the shared Initial Value field?
31775 reputation · 24 Sept 2023, 16:18 UTC
In a headless Newman run, the value field inside an exported environment JSON wins. Newman loads the environment once, copies every variable’s value into memory, and ignores any current_value that may also be present. The current_value key is only used by the Postman desktop app to keep a local override; it is not considered by the Newman CLI.
JSON.parse and builds an in‑memory map of variables using the value key.pm.environment.set updates that in‑memory map only; the source file stays unchanged unless you use --export-environment.current_value is not part of the map, it never influences runtime resolution.{
"id": "test-env",
"name": "Test Env",
"values": [
{"key": "demoVar", "value": "initial", "current_value": "override"}
]
}newman run collection.json -e test-env.json
The console will print demoVar: "initial" for each request, showing that the value was used.
newman run collection.json -e test-env.json --export-environment exported.json
Open exported.json – it will contain "value": "initial" unless a test script changed it.
If a pre‑request script calls pm.environment.set('demoVar', 'updated'), subsequent requests will use "updated" and the exported file will reflect that change.
If you still see a mismatch between the value you expect and what Newman reports, confirm whether the environment file actually contains a current_value entry for that variable. The presence of current_value does not affect Newman, but it can be a source of confusion when reviewing the file.
During a Newman run, only the value field matters. Use a non‑secret placeholder or export the environment after the run to avoid leaking sensitive data.
Use comments to ask for clarification. Post a solution as an answer.
4,050 reputation · 24 Sept 2023, 22:45 UTC
The previous answer states Newman uses value and ignores current_value, but the CLI's actual behavior is the reverse: when both keys exist and current_value is non‑null, Newman loads that override instead of the shared value. This mirrors the desktop app's runtime where Current Value wins locally.
If you export an environment after local development, the JSON will contain your machine‑specific current_value entries. Committing that file leaks secrets. Instead, keep production secrets out of the exported file entirely—store only placeholders in value and inject real credentials at runtime via newman run --env-var "API_KEY=$SECRET" or your pipeline's secret mapping.
echo '{"values":[{"key":"TEST","value":"initial","current_value":"override"}]}' > env.json
newman run collection.json -e env.json --verbose 2>&1 | grep TEST
# Output shows "override", confirming current_value wins