API Testing with Postman Tutorial: A Working Engineer’s Walkthrough

Most production bugs do not live in the UI. They live in the API. The QA engineers who can test that layer are the ones who get promoted twice as fast. This tutorial gets you started the way real teams use Postman, not the way a marketing video shows it.

Why API testing matters more than UI testing

The user interface is one face of a product. The API is what actually makes it work. When the API breaks, every UI built on top of it breaks. When the API behaves correctly, recovering from a UI bug is fast. The bugs that take down production are usually API bugs that the QA team did not catch because nobody tested below the UI layer.

What you need to know before opening Postman

HTTP fundamentals matter more than any tool. The basics:

• Methods. GET reads. POST creates. PUT replaces. PATCH updates partially. DELETE removes.
• Status codes. 2xx success, 3xx redirect, 4xx client error, 5xx server error.
• Headers. Metadata carried with the request and response. Authentication, content type, caching.
• Body. The payload. Usually JSON. Sometimes form data, occasionally XML.
• Query parameters. Key-value pairs in the URL after the question mark.

You can spend ten years using Postman and never need anything beyond these. The tool is a wrapper. The skill is in the fundamentals.

Your first request

Install Postman. Create a new request. In the URL field, paste this:

https://jsonplaceholder.typicode.com/posts/1

Hit Send. You should get back a JSON response with a 200 status code. Congratulations. You just made your first API call. Look at the response. Notice the status code at the top, the response time, the headers tab, and the body tab. Each of those is something you might want to assert on in a real test.

Collections: organizing your tests

A single request is a toy. A collection is a tool. Collections group related requests, store shared variables, and let you run a sequence of tests with one click.

Create a collection called “JSONPlaceholder API Tests”. Add four requests to it:

1. GET /posts/1 (read a single post)
2. GET /posts (list all posts)
3. POST /posts (create a new post)
4. DELETE /posts/1 (delete a post)

For the POST request, switch the method to POST in the URL bar, click the Body tab, select “raw” and “JSON”, and paste a sample body:

{
  "title": "My test post",
  "body": "Body content here",
  "userId": 1
}

Hit Send. You will get back a 201 Created with the new resource. The API is fake so the post does not really persist, but the response is real.

Environments: stop hard-coding URLs

Hardcoding base URLs in every request is the fastest path to a unmaintainable test suite. Use environments instead. Click the eye icon top right, create a new environment called “Dev”, and add a variable:

• Variable: base_url
• Value: https://jsonplaceholder.typicode.com

Now in your requests, replace the hardcoded URL with {{base_url}}/posts/1. Switch environments and your entire collection points somewhere else without editing a single request.

Tests: assertions that actually validate

Postman lets you write JavaScript-based tests that run after each request. The Tests tab is where this happens. Some essential patterns:

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

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

// JSON schema validation
pm.test("Response has required fields", function () {
  const json = pm.response.json();
  pm.expect(json).to.have.property('id');
  pm.expect(json).to.have.property('title');
  pm.expect(json.userId).to.be.a('number');
});

// Header check
pm.test("Content-Type is application/json", function () {
  pm.expect(pm.response.headers.get('Content-Type'))
    .to.include('application/json');
});

Run your request. The Test Results tab shows pass/fail for each assertion. This is where Postman starts feeling like a real testing tool.

Chained requests: when one response feeds the next

Real API tests rarely run in isolation. You log in to get a token, then use that token to fetch a resource, then use the resource ID to update something else. Each request depends on the last.

Postman handles this through environment or collection variables that get set in one request’s Tests tab and read in the next request’s URL or body.

// In the login request's Tests tab:
const json = pm.response.json();
pm.environment.set("auth_token", json.token);

// In the next request's headers:
// Authorization: Bearer {{auth_token}}

Once you understand this pattern, you can build any chain of requests, no matter how complex.

Pre-request scripts: the setup phase

Sometimes you need to do work before a request fires. Generate a unique email, create a timestamp, sign a request, refresh a token. The Pre-request Script tab is where this lives.

// Generate a unique email for each test run
const timestamp = Date.now();
pm.environment.set("test_email", `test+${timestamp}@example.com`);

Now in your request body, you can use {{test_email}} and get a fresh value every time.

The Collection Runner: automation built in

Click the Run button on any collection. Postman opens the Collection Runner. You can run all requests in sequence, set iteration counts, attach data files for data-driven runs, and view results in a clean summary.

This is the foundation of CI integration. Once your collection runs cleanly in the Runner, you can export it and run it from the command line using Newman, Postman’s CLI tool. From there, it plugs into GitHub Actions, GitLab CI, Jenkins, or any pipeline you have.

npm install -g newman
newman run my-collection.json -e dev-environment.json

Authentication patterns you will see in the wild

• Bearer tokens. Most common. Header: Authorization: Bearer your-token-here
• Basic auth. Username and password base64-encoded. Easy to set up in Postman’s Authorization tab.
• API keys. Either in headers or query parameters. Service-specific.
• OAuth 2.0. The full dance with authorization codes, tokens, and refresh tokens. Postman has a built-in helper.

What separates a beginner from an intermediate API tester

Three skills.

1. Schema validation. Not just checking that fields exist, but validating their types, formats, and value ranges. Use Ajv or similar libraries through Postman’s tests.
2. Negative testing. What happens when you send a malformed payload. A wrong content type. An expired token. A field that exceeds the maximum length.
3. Idempotency and side effects. Does running this request twice cause a problem. Does it correctly handle the case where it has already been run.

Where Postman ends and code begins

Postman is excellent for exploration, manual API testing, and lightweight automation. For heavy production-grade automation, most teams move their API tests into code, using Playwright’s APIRequestContext, Jest with Supertest, or Pytest with Requests in Python. The skills you learn in Postman transfer directly. Once you can articulate what a good API test looks like, the language is just syntax.

The first project that proves you can do this

Pick any free public API. JSONPlaceholder, GitHub’s API, the OpenWeatherMap API. Build a Postman collection that covers ten endpoints. Add tests to each. Wire up environments. Run the collection through Newman. Push it to GitHub with a clean README. That project on your portfolio will get more interview callbacks than three certifications.

Written by

Anveet Singh Chhabda

QA engineer and software testing educator. Manual testing, Playwright automation, and API testing taught from real-world product experience.