Postman Runner
You use the postman runner to send a whole group of API requests in order. You pick a folder of calls, set your loop count, and start the batch run. Engineering teams often use this tool to test apps or load data fast. Still, teams often put broad admin keys into shared workspace variables for these runs. When a role has too much power, one bad batch loop can wipe out records. How a postman runner workflow operates A batch run starts with a collection of saved API calls. Each call in the list
Runner: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use the postman runner to send a whole group of API requests in order. You pick a folder of calls, set your loop count, and start the batch run. Engineering teams often use this tool to test apps or load data fast. Still, teams often put broad admin keys into shared workspace variables for these runs. When a role has too much power, one bad batch loop can wipe out records.
How a postman runner workflow operates
A batch run starts with a collection of saved API calls. Each call in the list has an endpoint, a method, and a payload. The tool reads your collection from top to bottom during the run. You can also attach a data file with rows of test values. The runner loops through the collection once for each row in your file. It pulls values from the file and puts them into the request fields.
Before each call goes out, pre-request scripts can run to set up variables. These scripts might build a timestamp or format a string for the next step. After the server replies, test scripts check the status code and response body. One script can grab an ID from a reply and save it. The next request in the batch then uses that saved ID right away. This chain lets teams test full user flows from start to finish.
How teams manage keys and data files
Every API batch needs a valid token or key to log in. Teams store these secrets inside variable sets for each stage, like test or live. When an engineer starts a run, they select the matching variable set from a list. The tool swaps placeholder tags with the real secret values during the run. Workspace roles decide who can view or edit these shared variable sets.
Data files add another layer to how teams set up their batch jobs. Engineers build text files with columns for user IDs, emails, or account states. The runner reads one line at a time and sends the API call. If a team member picks the wrong variable set, test data hits live servers. Even with workspace roles, local runs still use the full power of that key.
Runner: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native setups solve and what they miss
Native workspace roles and variable scopes help teams organize their work well. They let leads control who can edit shared collections or read stored keys. This setup stops a new user from changing a shared test script by mistake. It also keeps staging urls separate from live urls during daily work. These features make it easy for groups to share and run API suites.
Still, a native setup only decides who can hold a key or start a run. It does not check what each request in the batch does in flight. Once a key logs in, the target server trusts every call in the loop. If a batch sends five hundred delete calls, the server runs them all. Native logs on the client device also fall short for central audit needs. And when replies come back, raw phone numbers or card numbers show up on screen. Masking is needed to rewrite matched fields like emails or national IDs in results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do you pass data between requests in a postman runner batch?
You write a short test script that reads the response from the first call. That script saves the value into a variable so the next call can read it.
Why do batch runs fail when switching from local tests to shared runs?
Batch runs often fail when secret values only exist in your local variable scope. You must move those values to a shared scope or attach the right data file.
How can teams stop a batch loop from changing live data by mistake?
Use read-only keys for test runs and keep live keys out of shared workspaces. You should also review every write call in a collection before starting a big loop.