How to load test an API behind a firewall

October 26, 2026

Your functional tests pass on every build. Then you run the load test against staging and get a wall of 403s, because the firewall has never seen the load generator’s IP address.

To load test an API behind a firewall, your endpoint should be visible to the load generators that are generating load from a remote IP. To make this possible, preferably these loads should come from a standard list of Static IP addresses that you can allowlist. This way, you can check the test on a machine you trust first, then scale it out from the allowlisted source.

Run it against beta or staging as a release gate, before production traffic finds the bottleneck for you.

Why does a load test end up behind the firewall?

Imagine running a team responsible for a checkout API. You want to have a simple rule – at 500 concurrent users, 90th percentile (p90) latency stays under 500 ms and errors stay under 1%. If staging misses that, the build doesn’t go to production.

This means your load test should run on your staging infra, where the network is tightest. Here, staging-api.example.com has a public address, but its web application firewall (WAF) only admits the office network and the continuous integration (CI) runners’ network address translation (NAT) gateway. Everything else gets a 403.

The functional tests pass through fine, because they come from those allowlisted CI runners like a Private runner in Postman. The load test is the problem – One CI runner can’t produce 500 virtual users, and a cloud load generator sends traffic from addresses the WAF has never seen.

How do teams usually get load through a firewall?

There are four common approaches. Each one is reasonable in some situations.

If your API has no public address at all, the self-hosted route is still the right one. For the far more common case, where the endpoint is public but filtered by source IP, you need two things together: load from managed infrastructure and a short, stable list of source addresses.

How do you load test an API behind a firewall, step by step?

The rest of this post walks through that setup in Postman, using the checkout team’s collection. Postman runs a performance test from the same collection you use for functional tests. Request order, pre-request and post-response scripts, and pm.test() assertions run under load exactly as they do in a single run.

1. Start from the collection you already have

The collection signs in, adds an item to the cart, and places an order. Each request already carries its assertions:

No separate load script is needed.

2. Smoke test locally

Before spending anything on cloud capacity, check that the test itself is sound. In the Collection Runner, set Run type to Performance and Run method to App, then run 10 to 20 virtual users for a few minutes. The same check from a terminal looks like this:

Watch the system metrics during the run. If your CPU is close to its limit, the latency you see is partly your laptop’s. The goal here is to catch broken variables, failing assertions, and obvious slow endpoints, not to measure capacity. For more on moving a test from your laptop to the cloud, read Cloud Performance Testing with Postman: From Laptop to CI.

3. Allowlist Postman’s static IPs

Ask your security team to add Postman’s static IP addresses to the WAF rule or security group that protects staging. The addresses depend on your Postman account’s region: US by default, or EU for EU Data Residency plans. Copy the current list for your region from the static IPs section of the performance test docs rather than from this post, since the list can change.

The load still comes from Postman’s cloud infrastructure. You allowlist the addresses it sends from, and nothing is installed in your network.

4. Run it in Postman Cloud from static IPs

Switch Run method to Cloud. Set 500 virtual users, choose a Ramp up load profile so the API warms up before the peak, and set the duration. Under Egress routing strategy, select Static IPs. Under Pass test if, set p90 less than 500.

Postman spreads the load across managed workers, so the virtual user count isn’t limited by one machine. Metrics, errors, and assertion results stream in while the run is going. If something is clearly wrong in the first minute, stop the run to avoid paying for virtual user (VU) hours you don’t need. The finished report is saved to the workspace, so anyone on the team can open it later.

5. Make it the release gate in CI/CD

Once the cloud run is clean, put the same test in your pipeline. The --runner postman-cloud-static-ip option sends the load from the static IP addresses, and --pass-if sets the exit code:

The command stays attached until the cloud run finishes, then exits non-zero if the threshold isn’t met. That fails the job and stops the promotion. Set the job’s timeout to at least the test duration.

How do you tell it’s working?

Four checks show whether the setup is doing its job:

• No firewall errors. The run’s errors view should show no 403s or connection resets from the WAF. If it does, an address is missing from the allowlist, or the allowlist covers the wrong region’s addresses.
• Local and cloud agree at low load. Run 20 virtual users locally and in the cloud. If local p90 is much higher and your CPU was saturated, your earlier local numbers measured the machine.
• A known breaking point. Step the virtual user count up across a few cloud runs and note where the error rate crosses 1%. That number is your current capacity, and it’s the number to defend in review.
• A trend, not a snapshot. Compare p90 across releases in the workspace’s run history. A gate that has never failed may be set too loose.

When aren’t static IPs the answer?

• Private-only hosts. If the API has no public address, allowlisting can’t help. Run the Postman CLI inside the network with the default local runner instead, which is limited by that machine’s resources.
• Allowlisting isn’t authentication. An IP allowlist narrows who can reach the endpoint. Keep the API’s own auth in place and pass credentials through the collection, using shared vault secrets for cloud runs.
• Region is fixed by your account. Cloud runs send traffic from your account’s region: the US by default, or the EU for EU Data Residency plans.
• Very small tests. Cloud runs need at least 10 virtual users. Below that, a local run is simpler.

Frequently asked questions

Which Postman plans include static IPs for cloud performance tests?

Static IPs for cloud performance tests are available on Postman paid plans. They were previously limited to Enterprise. Cloud performance test runs consume VU hours whether or not they use static IPs, and the Postman pricing page lists current rates.

How do I run a Postman cloud performance test from static IPs in CI/CD?

Use the Postman CLI with the static IP runner: postman performance run <collection-id> --runner postman-cloud-static-ip. Add --pass-if with a threshold such as less_than(p90, 500). The command waits for the cloud run to finish and exits non-zero when the threshold isn’t met, which fails the CI/CD job.

Do static IPs work for APIs with no public address?

No. Static IPs for Postman cloud performance tests work for publicly addressable endpoints that filter traffic by source IP. If an API is reachable only on a private network, run the Postman CLI inside that network with the default local runner. That run generates load from the machine it’s on and is limited by its resources.

Should I load test locally or in Postman Cloud?

Use both. A local Postman performance run in the app or CLI is a quick smoke test that catches broken variables and failing assertions at 10 to 20 virtual users. A cloud run spreads hundreds of virtual users across Postman’s managed workers, so results aren’t limited by one machine’s CPU or network.

Next step

Static IPs for cloud performance tests are available on Postman paid plans. Set up your first run with the guide to running a cloud performance test from static IPs.