Write real tests, not just requests.
Pre-request and post-response scripts run in a sandboxed JavaScript environment with a pm/titan-compatible API subset — set up state before a call goes out, and assert on the response the moment it comes back.
Automate what you'd otherwise eyeball.
Three things scripting replaces with something repeatable.
Catch regressions automatically
A pm.test() assertion runs the same way every time — a broken response shows up as a red line in the results panel, not something you notice three requests later.
Chain requests together
Save a value from one response as a variable in a post-response script, then reference it in the next request — no manual copy-pasting between calls.
Keep secrets out of scripts
Variables marked secret resolve correctly when a request sends, but pm.environment.get() returns nothing for them — a script can't leak what it can't read. This is the same pattern covered in the pre/post-request workflow guide, alongside the rest of the scripting reference.
Pre-request setup, post-response assertions.
The same two-script pattern on every request.
Scripting, answered.
The practical questions before you write your first script.
Is this the same as the real Postman sandbox?
No. It's a pm/titan-compatible API subset running in its own sandboxed JavaScript environment — the common pm.test/pm.expect/pm.environment surface works, but it isn't a byte-for-byte reimplementation of every Postman-specific API.
Can a script access the filesystem or make its own network calls?
No. Scripts run in an isolated sandbox with no filesystem access and no ability to make arbitrary network requests of their own, plus a hard timeout so a runaway script can't hang a request.
Can a script read a variable I've marked secret?
No — pm.environment.get() returns nothing for a secret-flagged variable, even though the request itself still resolves and sends the real value correctly.
Where do assertions show up?
In a dedicated results panel after the request runs: a pass/fail summary, then each test by name with its duration, and the actual error for anything that failed.
Talk to us.
Tell us about your team and what you're building. We'll get back to you.