20Postman Deep-Dive

20.1 Anatomy of a Postman request

20.2 Authorization types — exhaustive

20.3 JWT — what's inside that token

A JWT (JSON Web Token) is just three base64-url chunks joined by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0Iiwicm9sZSI6ImFkbWluIn0.4Adcj3UFYzPUVaVF43FmMab6RlaQD8A9V8wFzzht-KQ
└──── header ────┘ └──────── payload ────────┘ └────────── signature ──────────┘

Standard claims (RFC 7519)

• iss — issuer
• sub — subject (usually user id)
• aud — audience (intended recipient)
• exp — expiry (unix seconds)
• nbf — not before
• iat — issued at
• jti — token id (for revocation)

Using a JWT in Postman

1. POST to /auth/login with credentials
2. In the Tests tab: pm.collectionVariables.set('token', pm.response.json().access_token)
3. On other requests, Authorization → Bearer Token → {{token}}

20.4 OAuth 1.0a vs OAuth 2.0 — the real difference

OAuth 2.0 grant flows (Postman supports all)

20.5 Variables & scopes

Reference: {{baseUrl}}/users/{{userId}}. Resolution order: data → local → environment → collection → global.

20.6 Pre-request & Tests scripts

Pre-request — runs BEFORE sending

// Compute a signed HMAC header
const ts = Date.now();
const body = pm.request.body.raw || '';
const sig = CryptoJS.HmacSHA256(ts + body, pm.environment.get('signingKey')).toString();
pm.request.headers.add({ key: 'X-Timestamp', value: ts });
pm.request.headers.add({ key: 'X-Signature', value: sig });

Tests — runs AFTER response (assertions + capture)

// Status assertion
pm.test('status 200', () => pm.response.to.have.status(200));

// JSON schema assertion
pm.test('response has user', () => {
  const body = pm.response.json();
  pm.expect(body).to.have.property('id');
  pm.expect(body.email).to.match(/@/);
});

// Capture value for next request
const token = pm.response.json().access_token;
pm.collectionVariables.set('token', token);

// Conditional next request
postman.setNextRequest('Verify Token');   // skip to a specific request in the run
// postman.setNextRequest(null);          // stop the runner

20.7 Collections, folders, runner

• Collection — a group of related requests with optional collection-level auth and variables
• Folder — nested grouping inside a collection (e.g. "Users", "Orders")
• Collection Runner — runs requests sequentially with delay, iterations, data file. Outputs per-request results.

Data-driven runs

Upload a CSV / JSON file. Postman runs the collection once per row, with each row's columns available as {{column}}.

// users.csv
email,role
alice@test.com,admin
bob@test.com,user
carol@test.com,viewer

Request body becomes {"email": "{{email}}", "role": "{{role}}"}. Three iterations run automatically.

20.8 Newman — Postman in CI

Newman is Postman's CLI. Export the collection JSON, commit it, and run on CI.

npm i -g newman
newman run my-collection.json -e staging.postman_environment.json \
  --iteration-data users.csv \
  --reporters cli,htmlextra,junit \
  --reporter-junit-export results/junit.xml

# GitHub Actions
- uses: actions/setup-node@v4
  with: { node-version: '20' }
- run: npm i -g newman newman-reporter-htmlextra
- run: newman run my-collection.json -e prod.json --reporters cli,htmlextra
- uses: actions/upload-artifact@v4
  if: always()
  with: { name: newman-report, path: newman/ }

20.9 Mock servers and monitors

• Mock server — Postman hosts a fake endpoint that returns saved example responses. Useful for parallel front-end development.
• Monitor — schedule a collection to run on Postman's cloud (every N minutes). Sends alerts on failures. Lightweight uptime/synthetic monitoring.

20.10 When to use Postman vs Playwright API vs REST Assured