How to Test REST APIs with Postman — Collections, Env Vars, and Automation

Postman is often used just as a place to click "Send" and eyeball a JSON response, but it's capable of a lot more: organized collections, environment-driven configuration, scripted assertions, and full CI automation. This guide walks through setting all of that up properly.

Organizing Requests into Collections

A collection groups related requests, usually mirroring your API's resource structure. Use folders inside a collection to group by feature area.

• Users API — Create User, Get User, Update User, Delete User
• Orders API — Create Order, List Orders, Cancel Order
• Auth — Login, Refresh Token, Logout

Save each request with a descriptive name and a short description of what it verifies — future you (and your teammates) will thank you.

Environment Variables

Hardcoding https://api.example.com into every request makes it painful to switch between local, staging, and production. Define variables in a Postman Environment instead.

// Environment: "Local"
baseUrl = http://localhost:5000
authToken = (empty, filled in by a test script after login)

// Environment: "Production"
baseUrl = https://api.example.com
authToken = (empty)

// Request URL uses the variable instead of a hardcoded host
{{baseUrl}}/api/users/42

// Authorization header
Authorization: Bearer {{authToken}}

Switching environments in the top-right dropdown instantly repoints every request in the collection — no find-and-replace needed.

Writing Test Assertions

The Tests tab on a request runs JavaScript after the response arrives, using Postman's built-in pm object.

pm.test('Status code is 200', function () {
  pm.response.to.have.status(200);
});

pm.test('Response has expected user shape', function () {
  const body = pm.response.json();
  pm.expect(body).to.have.property('id');
  pm.expect(body).to.have.property('email');
  pm.expect(body.id).to.equal(42);
});

pm.test('Response time is under 500ms', function () {
  pm.expect(pm.response.responseTime).to.be.below(500);
});

// Save a token from the login response for use in later requests
pm.test('Save auth token', function () {
  const body = pm.response.json();
  pm.environment.set('authToken', body.token);
});

That last example is powerful: the Login request's test script saves the returned token into authToken, and every subsequent request in the collection automatically uses it via {{authToken}}.

Chaining Requests with the Collection Runner

The Collection Runner executes every request in a folder in order, running each request's tests and reporting pass/fail for the whole suite. This is how you simulate a full user flow: login, create a resource, read it back, then delete it.

1. Open the collection, click "Run"
2. Select the environment (Local, Staging, etc.)
3. Choose the requests/folders to include and the run order
4. Click "Run" and review the pass/fail summary for each request's assertions

Automating with Newman

Newman is Postman's command-line collection runner, letting you run the exact same tests in a CI/CD pipeline instead of manually clicking "Run" in the GUI.

npm install -g newman

# Export your collection and environment as JSON from Postman first
newman run users-api.postman_collection.json \
  -e staging.postman_environment.json \
  --reporters cli,junit \
  --reporter-junit-export results.xml

# GitHub Actions step
- name: Run API tests
  run: |
    npm install -g newman
    newman run users-api.postman_collection.json -e staging.postman_environment.json

Newman exits with a non-zero code if any test fails, so it plugs directly into a CI pipeline as a pass/fail gate before deployment.

Frequently Asked Questions