Three Postman Features You're Missing If You Only Hit Send

A lot of people use Postman just to build one request and hit Send. But there's a layer above that: environments, the Collection Runner, and pre-request scripts. They handle switching between dev and production, running the same request repeatedly, and transforming values right before a request fires. This post lays out where to turn each feature on, the core usage, and the limits worth knowing up front — all based on the official docs.

Three repetitive tasks the tool does so you don't have to

When you're testing an API, the work around the request often eats more time than the request itself. You're looking at the dev server, then you want to check staging, so you edit the URL by hand. You hit Send on ten test cases one at a time. You copy an expired token from another request and paste it into a header.

Postman solves each of these with a separate feature. None of them require an extra install — they're all built into the default UI.

Environments — switching between dev and production becomes one click

An environment is a bundle of variables. You give the same variable name a different value per environment, then send the same request to a different server just by switching the active environment.

Creating and switching environments

Create one from the new (+) icon in the sidebar by selecting Environments, or from the environment selector at the top right of the workspace by clicking the add icon. Name the environment, enter variable names and values, and it saves automatically. For example, you might create a dev environment and a production environment, both holding a variable called base_url but with different values.

To switch the active environment, pick it from the environment selector at the top right, or click the checkmark icon next to an environment in the sidebar's Environments list.

Variable reference syntax

Reference variables anywhere — the request URL, headers, or body — with double curly braces. Write this in a URL and it's replaced with the value from the active environment.

GET {{base_url}}/api/v1/orders/{{order_id}}

// Reading and writing from a script
pm.environment.get("base_url");
pm.environment.set("order_id", "12345");

Variable values stay local by default

A value you enter into a variable is used when you send requests from your own local Postman instance; by default it isn't synced to the Postman cloud or shared with your team. To share values with your team, you set a separate shared value, and that does sync to the cloud. For sensitive values like API keys, you can use the icon next to the variable name to Mark as sensitive.

Collection Runner — run a bundle of requests repeatedly with a data file

The Collection Runner runs the requests inside a collection or folder in order, all at once. Pick a collection in the sidebar, click Run, and choose Run manually on the Functional tab to bring up the run configuration screen.

Run options

• Iterations — how many times to repeat the whole collection.
• Delay — the gap between requests, in milliseconds. Use it when hitting a server with rate limits.
• Persist responses for a session — records response headers and bodies so you can review them after the run finishes.
• Under Advanced settings, you can enable stop-on-error, keep variable values, exclude cookies, and more.

Requests run in the order they're listed in the collection, and you can drag to reorder them on the run configuration screen. On the results screen, you filter test results with the Passed · Failed · Skipped tabs.

100 cases at once with a data file

The runner's real value shows up when you pair it with a data file. Upload a CSV or JSON file and each row in the file becomes one iteration, with each row's values filling in the variables inside the request. Write your boundary values and error cases out as rows, and the same request runs as many times as there are cases.

order_id,coupon_code,expected_status
1001,WELCOME10,200
1001,EXPIRED99,400
9999,WELCOME10,404

In a CSV, the first row is the variable names and the rows below it are data. Reference a variable by name in the request body or URL — like {{coupon_code}} — and each iteration pulls in that row's value.

Pre-request scripts — JavaScript runs right before the request fires

A pre-request script is JavaScript that runs before a request is sent. Use it to set variables, parameters, headers, or body data dynamically, or to log to the console. Select a request and write the code in the Pre-request tab under the Scripts tab.

There are three places to attach it

Beyond an individual request, you can attach the same way to a folder or a collection. Attached to a collection, it runs before every request in that collection; attached to a folder, it runs before the requests directly under that folder. For logic common to every request, like setting an auth token, it's easier to manage if you put it once at the collection level instead of copying it into each request.

// Collection-level pre-request example: refresh a timestamp per request
pm.environment.set("request_ts", new Date().toISOString());

// Then in a request header
// X-Request-Time: {{request_ts}}

Paired with the Collection Runner, you can also build a flow that takes a response value from one request and passes it to the next. A classic pattern: pull a token from a login response, save it to a variable, and have the following requests reference that variable.

Pitfalls worth knowing in advance

• Manual collection runs have a monthly limit. Postman caps the number of monthly collection runs per plan, and this limit applies to manual runs (Run manually). Even with many iterations, it counts as one run.
• CSV format rules are strict. The first row must be variable names, every row must have the same number of columns, and line endings must be Unix-style. If the runner can't read your file, checking these three is the fastest fix.
• Check the contents before setting a shared value. Setting a variable value to share with your team syncs it to the cloud. Put a variable holding a token into a shared value and it's exposed to your team as-is — so keep sensitive values as local values only and Mark as sensitive to be safe.
• Editing team environments requires the Editor role. To edit an environment and change shared values, you need the Editor role on that environment.
• Collection scripts apply to every request. A collection-level pre-request runs before every request beneath it, so putting logic that only one request needs at the collection level affects all the others too.

If it's already installed, start with environments

None of the three need a separate install, so the adoption cost is essentially just the learning time. If you're picking an order, environments come first. Pulling just base_url out into a variable eliminates editing the URL on every server switch, and the other two features all work on top of variables.

Next is the Collection Runner. For an API with a pile of cases to validate repeatedly, a single CSV gives you a regression test bundle. Bring in pre-request scripts at the point you find yourself doing the same preprocessing by hand every time, like refreshing a token.

Note: Environments and pre-request scripts have no limits even on the free plan, but manual collection runs have a monthly cap per plan. If you plan to run the runner often as a team, check your current plan's limit first.

Sources

• Postman Docs — Group sets of variables using environments
• Postman Docs — Edit and set environment variables
• Postman Docs — Test your API using the Collection Runner
• Postman Docs — Write pre-request scripts

This post is an objective write-up based on the official docs, not a hands-on report. Menu layouts and per-plan limits can vary by version and plan, so check the official docs alongside it.

Original with full infographics and visual structure: https://jessinvestment.com/three-postman-features-youre-missing-if-you-only-hit-send/