Chapter 4: Environment Variables and Data-Driven Tests
You now know how to use variables, set up environments, chain requests, and run data-driven tests. Time to talk about doing it RIGHT. Because there is a big difference between "it works" and "it works and won't blow up in production."
Your future self will read your variable names at 11 PM during a production incident. Be kind to that person.
| Bad Name | Good Name | Why |
|---|---|---|
| url | baseUrl | "url" is too generic — base URL? callback URL? redirect URL? |
| token | authToken | Clarifies it is the auth token, not a CSRF token or reset token |
| id | createdUserId | What ID? User? Post? Order? Be specific. |
| data | orderPayload | "data" means nothing. What data? |
| test1 | loginTestEmail | Names should describe what the variable holds |
| x | iterationCount | Single letters are for math class, not test suites |
This is where people get fired. You put an API key in Initial Value. It syncs to Postman cloud. Someone exports the collection. The key ends up on GitHub. A bot scrapes it. Your AWS bill hits $50,000. This is not hypothetical — it happens every week.
NEVER put secrets in Initial Value — they sync to Postman cloud
Use "secret" variable type — Postman masks the value in the UI
Set sensitive values ONLY in Current Value — stays on your machine
Use pre-request scripts to generate tokens dynamically instead of storing them
Add a .gitignore entry if you export environments: *.postman_environment.json
Rotate credentials regularly — automated tests should use test-only API keys
Never commit Postman environment files to version control
If you accidentally synced a secret to Postman cloud, changing the Current Value is NOT enough. The secret is already in sync history. You must rotate the credential immediately — generate a new API key, revoke the old one.
// In the LAST request of your collection, add a cleanup script:
// Remove temporary variables created during the run
pm.environment.unset("createdUserId");
pm.environment.unset("createdPostId");
pm.environment.unset("tempToken");
// Or clear ALL environment variables (use with caution)
// pm.environment.clear();
// Log cleanup
console.log("Cleanup complete. Temporary variables removed.");| Mistake | What Happens | Fix |
|---|---|---|
| Storing secrets in Initial Value | Synced to cloud, visible to team | Use Current Value + secret type |
| Not cleaning up variables | Stale data causes flaky tests | Unset temp variables in last request |
| Using global variables everywhere | Name collisions across collections | Prefer collection/environment scope |
| Hardcoding in one "just this once" | Forgotten, breaks on env switch | Always use variables — no exceptions |
| Same environment for all projects | Variable name conflicts | One environment per project per stage |
Key Point: Good variable hygiene: descriptive camelCase names, secrets in Current Value only, clean up temp variables after runs, and never commit environment files to git.
Q: How do you handle sensitive data like API keys and passwords in Postman?
A: Never store sensitive data in Initial Values — they sync to Postman cloud and are included in exports. Use Current Values which stay local. Set the variable type to "secret" so the value is masked in the UI. Better yet, use pre-request scripts to generate tokens dynamically (like calling a login endpoint). For team sharing, document which variables need to be filled in but never include actual credentials. If environment files are exported, add them to .gitignore. Always use test-only credentials, not production keys.
Key Point: Name variables descriptively. Never put secrets in Initial Value. Clean up temporary variables. Treat your Postman collection like production code.