API Testing with Postman

You now understand what an API is and how HTTP works. It is time to actually drive one. Postman is the tool the industry reaches for first — a friendly workbench where you build requests, inspect every byte of the response, organise your work into reusable suites, and eventually write automated checks that run themselves. By the end of this module you will have a real, saved collection hitting a live public API, powered by variables and environments like a professional does on the job.

Getting started: installing and understanding Postman

Download Postman from postman.com/downloads — it is free for individuals and runs on Windows, macOS and Linux. There is also a browser version, but the desktop app is recommended because it can reach APIs running on your own machine (localhost). You can sign in to sync your work to the cloud, or skip sign-in and work locally; either is fine for learning.

When Postman opens, orient yourself around four areas you will use constantly:

The sidebar (left)

Your Collections, Environments and request History live here. This is where your saved work is organised.

The request builder (top centre)

A method dropdown (GET, POST, …), the URL bar, and the Send button. Below it are tabs: Params, Authorization, Headers, Body, Tests, and more.

The response panel (bottom centre)

After you hit Send, this shows the body, the status code, the response time, the size, the response Headers, and the Test Results.

The Console

Open it with the console icon at the bottom-left. It shows the exact request Postman sent — final URL, headers, body — and anything you log. It is your single best debugging tool.

Building and sending your first request

Let us hit a live public API. We will use reqres.in, which returns realistic fake user data, and JSONPlaceholder.

1. Click New → HTTP Request (or the + tab).
2. Leave the method as GET and type https://reqres.in/api/users/2 into the URL bar.
3. Click Send. In the response panel you should see 200 OK, a response time of a few hundred milliseconds, and a JSON body containing a data object with user 2.

Read what came back — this is the whole point of the tool:

{
  "data": {
    "id": 2,
    "email": "janet.weaver@reqres.in",
    "first_name": "Janet",
    "last_name": "Weaver"
  }
}

Query parameters the easy way

Query params filter, sort or paginate. You can type them after a ? in the URL, but the Params tab is cleaner: add a key and value and Postman builds the query string for you. Try https://reqres.in/api/users with a param page = 2. Postman turns it into https://reqres.in/api/users?page=2, and you get the second page of users.

Sending a JSON body with POST

To create something, switch the method to POST, go to the Body tab, choose raw, and pick JSON from the format dropdown (this also sets the Content-Type: application/json header automatically). Point the URL at https://reqres.in/api/users and enter:

{
  "name": "Test Learner",
  "job": "QA Engineer"
}

Hit Send. You should get 201 Created and a body echoing your data plus a server-generated id and createdAt:

{
  "name": "Test Learner",
  "job": "QA Engineer",
  "id": "873",
  "createdAt": "2026-01-12T09:30:00.000Z"
}

Collections and folders: organising your work

A single request is useful once; a collection is useful forever. A collection is a saved group of related requests — think “User API” or “Checkout Service.” Inside a collection you add folders to group by feature: an Auth folder, a Users folder, an Orders folder. This structure is the backbone of an automated API regression suite.

1. Click New → Collection and name it Practice API.
2. Add folders inside it — for example Users and Posts.
3. Save each request you build into the right folder with Save (or Ctrl/Cmd+S), giving it a clear name like Get user by id.

Why this matters: a saved collection can be shared with your team, version-controlled, run as a batch, and documented automatically. A pile of unsaved tabs can do none of those things.

Environments and variables: stop hard-coding

Never paste the same base URL or token into twenty requests. Instead, define a variable once and reference it with double curly braces: {{variable_name}}. The most common is {{base_url}}.

An environment is a named set of variables — typically one per deployment:

1. Click the environments icon, then Create Environment, name it Staging.
2. Add a variable: name base_url, value https://reqres.in/api.
3. In your requests, use {{base_url}}/users/2 instead of the full URL.
4. Select Staging from the environment dropdown (top-right) so Postman knows which values to use.

Now create a second environment, Production, with a different base_url. To re-run your entire suite against production, you change one dropdown — every request follows. This is how one collection tests many environments.

The Tests tab: your first automated checks

Clicking Send and eyeballing the body does not scale. The Tests tab lets you write small JavaScript snippets that run after the response arrives and turn into green passes or red failures in the Test Results panel. The two building blocks are pm.test(name, fn) — which names and runs a check — and pm.expect(value) — which asserts something about a value.

Add these to the Tests tab of your GET {{base_url}}/users/2 request, then hit Send:

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

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

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

// 4) Parse the body once, then assert on its fields
const body = pm.response.json();

pm.test("Returns the user we asked for", function () {
    pm.expect(body.data.id).to.eql(2);
    pm.expect(body.data.email).to.be.a("string");
    pm.expect(body.data.email).to.include("@");
});

The pattern is always the same: parse the body with pm.response.json(), then make precise claims about it. We go much deeper on assertions in Module 4; for now, notice how readable it is — each pm.test reads almost like a sentence describing the contract.

Chaining requests: reuse a value from one response

Real workflows span multiple calls: create a user, then fetch that same user. To do that you save a value from one response into a variable and use it in the next request. In the Tests tab of a POST that creates a user:

const body = pm.response.json();
// Save the new id into the environment for later requests
pm.environment.set("user_id", body.id);
console.log("Saved user_id =", body.id);

Then a later request can use {{base_url}}/users/{{user_id}}. This “capture then reuse” pattern is the foundation of end-to-end API flows and is used heavily in the capstone.

Note: reqres.in is a mock API — the id it returns from a POST is not actually stored, so fetching it back with a GET will not find it. The chaining here is illustrative; against a real API the created resource would be retrievable.

The Collection Runner: run everything at once

Once your requests have tests, you can execute the whole collection in order. Click the collection’s ··· menu → Run collection. The Collection Runner lets you:

• Choose which requests run and in what order.
• Select the environment (Staging vs Production).
• Set an iteration count and attach a data file (CSV/JSON) to run the same requests with many sets of inputs — this is data-driven testing.
• See a summary of total passes and failures at the end.

This is the moment a collection stops being a toy and becomes a regression suite: one click re-verifies the whole API. The same collection can later be run from the command line with Postman’s CLI tool, Newman (newman run practice-api.json), which is how teams wire Postman tests into CI/CD pipelines.

Exporting and sharing

To hand your work to a teammate or save it as a portfolio piece, click the collection’s ··· menu → Export and choose the Collection v2.1 format. You get a single JSON file that anyone can Import to get your exact requests, folders and tests. Export the environment separately (the environments ··· menu) — but strip real secrets out first.

Practice API (collection)
  Users (folder)
    GET  {{base_url}}/users?page=2     -> expect 200, array of users
    GET  {{base_url}}/users/2          -> expect 200, data.id === 2
    POST {{base_url}}/users            -> expect 201, save {{user_id}}
    PUT  {{base_url}}/users/2          -> expect 200, updatedAt present
    DELETE {{base_url}}/users/2        -> expect 204, empty body

pm.test("Delete returns 204 No Content", function () {
    pm.response.to.have.status(204);
});
pm.test("Delete body is empty", function () {
    pm.expect(pm.response.text()).to.eql("");
});

pm.sendRequest({
  url: pm.environment.get("base_url") + "/login",
  method: "POST",
  header: { "Content-Type": "application/json" },
  body: { mode: "raw", raw: JSON.stringify({ email: "a@b.com", password: "x" }) }
}, function (err, res) {
  pm.environment.set("token", res.json().token);
});