How to Set Up and Use a Proxy in Postman

Postman is where most teams poke at an API before they write a line of client code. Routing it through a proxy lets you do three things you cannot do on a bare connection:

• Test from a specific region. Hit a geo-gated endpoint as if you were in the US, Germany, or Japan, and confirm the response actually changes by country.
• Reproduce what your scraper or backend sees. If production traffic leaves through a datacenter or residential proxy, testing from your laptop IP hides rate limits, blocks, and geo logic you will meet later.
• Stay under one exit while you debug. A sticky proxy IP keeps a login session or a rate-limit window stable across a run of requests.

When a target blocks even a clean proxy IP, the built-in proxy is the wrong tool and you switch to a scraping API instead. We cover that path in the per-request section using the SparkProxy Scraping API, which adds rotation, real-browser rendering, and anti-bot handling behind a single HTTPS call.

SparkProxy hands you an endpoint in host:port:user:pass form. A datacenter line looks like this:

proxy.sparkproxy.io:10000:sp-user-12345:A1b2c3d4e5

Postman splits those four parts across different fields, so keep this mapping in front of you:

If your plan uses IP whitelisting instead of a username and password, you skip the auth fields entirely and add your current IP in the dashboard. The trade-offs between the two are covered in how proxy authentication works and what IP whitelisting is.

One protocol note before the UI steps. Postman's proxy dropdown supports HTTP, SOCKS5, SOCKS5H, SOCKS4, and SOCKS4A. A standard SparkProxy HTTP endpoint uses the HTTP option, which still tunnels HTTPS traffic through CONNECT. Pick SOCKS5 only if you were issued a SOCKS endpoint. If the difference is fuzzy, read HTTP, HTTPS, and SOCKS5 proxy protocols.

Here is the fact that saves the most debugging time: Postman's proxy is one app-wide setting, not a per-request option. There is no proxy field on an individual request in the standard UI. Whatever you set in Settings applies to every request the app sends until you change it.

Postman gives you two built-in modes plus one workaround for varying the exit per request:

By default the desktop app follows the system proxy. Turning on Use custom proxy configuration overrides that and pins Postman to the host and port you type. The third row is not a real Postman proxy mode; it is the way to get per-request exit control, and we build it out in the per-request section.

These steps match Postman 11 on desktop. The labels are stable back through Postman 10.

Step 1. Open the Proxy tab. Click the gear icon in the top right, choose Settings, then click the Proxy tab. On the screen you see two blocks: Use system proxy at the top and Proxy configurations for sending requests below it.

Step 2. Turn on the custom proxy. Toggle Use custom proxy configuration on. The host, port, and auth fields become editable.

Step 3. Set which traffic uses the proxy. Under Use proxy for, both HTTP and HTTPS are checked by default. Leave both checked. This is the single most common mistake with Postman proxies: if you uncheck HTTPS and then call an https:// endpoint, Postman sends it directly and you will swear the proxy is broken while it sits there doing nothing.

Step 4. Enter the server. In the Proxy server row, leave the protocol dropdown on HTTP for a standard SparkProxy endpoint, then type the host and port:

Proxy server:  proxy.sparkproxy.io
Port:          10000

Step 5. Save and send. Settings apply immediately to new requests. Fire any request and move on to auth if your endpoint needs credentials.

At this point an IP-whitelisted proxy already works. A username and password proxy will return 407 Proxy Authentication Required until you finish the next section.

Most SparkProxy endpoints authenticate with a username and password rather than a whitelisted IP, which is what you want on a laptop with a changing IP.

In the Proxy tab, under the server fields, turn on the Proxy auth toggle. Two fields appear:

Username:  sp-user-12345
Password:  A1b2c3d4e5

Postman sends these as Basic proxy authentication in a Proxy-Authorization header on the tunnel, separate from any Authorization header your API request carries. The two never collide, so a proxy login and a bearer token to your API live side by side without interfering.

A few things that bite people here:

• Credentials are stored in plain settings. They are not encrypted at rest in the app config. On a shared machine, prefer IP whitelisting.
• Special characters are literal in these fields. Unlike a URL, you do not percent-encode the password in the Postman auth boxes. A password of p@ss:word goes in exactly as typed. You only encode it when you embed it in a URL, which matters for Newman.
• A wrong login looks like a network failure, not a 401. Proxy auth failures surface as 407, and Postman may show it as a generic error before the request ever reaches your API.

This is where a lot of Postman proxy setups fall over, usually with a misdiagnosis. A plain forwarding proxy does not touch the TLS handshake. A SparkProxy datacenter or residential endpoint tunnels your HTTPS bytes to the target untouched, so it should never cause a certificate error. If you see one, the proxy is almost never the cause.

The errors look like this:

unable to verify the first certificate
SELF_SIGNED_CERT_IN_CHAIN
unable to get local issuer certificate

You get these when something in the path intercepts TLS and presents its own certificate. In practice that is a corporate gateway or a debugging proxy sitting in front of your machine, not the SparkProxy exit. Two ways to handle it:

Proper fix, keep verification on. Export the intercepting proxy's root CA as a PEM file and add it in Settings, Certificates, CA Certificates. Postman then trusts that chain and verification stays honest for every other target.

Quick fix for testing only. Open Settings, General and turn off SSL certificate verification. This disables validation for all requests, so treat it as a temporary switch on a test machine, never a default. Turn it back on when you are done.

If you need client-certificate auth to the target itself (mutual TLS), add the client cert and key under Settings, Certificates, Client Certificates, scoped to the host. That is a separate mechanism from the proxy and from CA trust.

Never trust that a proxy is working because the request returned 200. Confirm the exit IP. The Postman Console shows you the raw network call, which is the fastest way to catch a request that bypassed the proxy.

Open the Console. Use View, Show Postman Console, or the shortcut Ctrl + Alt + C on Windows and Linux, Cmd + Option + C on macOS.

Send an IP echo request. Create a GET to an endpoint that returns the caller's public IP as JSON:

GET https://api.ipify.org/?format=json

The response body is the exit IP the world sees:

{ "ip": "185.203.44.17" }

Compare that value to your machine's real public IP and to the exit ranges listed in your SparkProxy dashboard. If it matches the proxy and not your laptop, routing works. The Console entry for the same request shows the request headers and the network call, so you can confirm Postman went through the proxy rather than falling back to a direct connection.

When the IP is still yours. If the Console shows the request but ip equals your real address, the proxy was bypassed. Walk this short list, in order:

1. Protocol checkbox. The target is https:// but HTTPS is unchecked under Use proxy for. This is the top cause.
2. Bypass list. The host matches an entry in Proxy bypass, so Postman skipped the proxy on purpose.
3. Wrong mode. You edited the custom proxy but left Use system proxy active, or vice versa.

For a deeper checklist that applies beyond Postman, see how to test if your proxy is working.

Because the built-in proxy is app-wide, you cannot template it with {{variables}}. The Proxy tab does not read environment variables, so a value like {{proxy_host}} in that field is treated as literal text. Two real ways exist to vary the exit per request.

Option A: separate environments, switch the custom proxy. Keep the proxy host, port, user, and pass as variables in each Postman environment for documentation, then change the custom proxy in Settings when you switch environments. It works, but it is manual and easy to forget.

Option B, the clean one: call the SparkProxy Scraping API. The Scraping API is a normal HTTPS endpoint, so no app-level proxy is involved at all. You control the exit country and behavior with query parameters, and those parameters can be environment variables. This is genuinely per-request, and it is also the answer when a target hard-blocks direct proxy traffic.

Set up a Postman environment with these variables:

{
  "base_url": "https://scrape.sparkproxy.io/api/v1",
  "api_key": "sk-live-your-key-here",
  "country": "us"
}

Then build one request that reads them. Add the key as a header and the target plus exit country as query params:

GET {{base_url}}?url=https://www.sparkproxy.io&render_js=false&country_code={{country}}
X-API-Key: {{api_key}}

Per the SparkProxy Scraping API docs, render_js=false runs a plain HTTP fetch (cheaper), country_code takes an ISO alpha-2 code, and X-API-Key carries your key. Duplicate the environment as an EU exit with "country": "de", switch environments, and resend the identical request. Same request, different exit country, and Postman's Settings never change. Add premium_proxy=true to route through residential IPs when a target is strict about datacenter ranges.

This pattern turns "which proxy?" into ordinary request data, which is what you wanted from a per-request proxy in the first place.

Newman runs your Postman collections from the command line and in CI. It does not read the desktop app's proxy setting, and it has no --proxy flag. Instead, Newman honors the standard proxy environment variables of the shell that launches it: HTTP_PROXY, HTTPS_PROXY, and NO_PROXY. Set them, then run.

On macOS and Linux:

export HTTP_PROXY="http://sp-user-12345:A1b2c3d4e5@proxy.sparkproxy.io:10000"
export HTTPS_PROXY="http://sp-user-12345:A1b2c3d4e5@proxy.sparkproxy.io:10000"
export NO_PROXY="localhost,127.0.0.1"

newman run collection.json -e us.postman_environment.json

On Windows PowerShell:

$env:HTTP_PROXY  = "http://sp-user-12345:A1b2c3d4e5@proxy.sparkproxy.io:10000"
$env:HTTPS_PROXY = "http://sp-user-12345:A1b2c3d4e5@proxy.sparkproxy.io:10000"

newman run collection.json -e us.postman_environment.json

Credentials live in the URL userinfo here, so percent-encode any special characters in the password. An @ becomes %40, a : becomes %3A. Miss this and the URL parser splits the password at the wrong character and you get a 407.

For a TLS-intercepting proxy in CI, Newman exposes the SSL flags the desktop app hides behind Settings:

# Trust the intercepting proxy's CA (the honest option)
newman run collection.json --ssl-extra-ca-certs ./proxy-ca.pem

# Skip verification for a throwaway test run only
newman run collection.json --insecure

# Client-certificate (mutual TLS) to the target
newman run collection.json \
  --ssl-client-cert ./client.crt \
  --ssl-client-key ./client.key

--insecure (short form -k) turns off SSL verification checks and allows self-signed certificates. Keep it out of any pipeline that talks to production.