API Testing with Postman: From a Single Request to Full Automation

Almost every modern web project is built on top of APIs. The frontend fetches data from a server, a mobile app talks to the cloud, and payment systems exchange requests with one another. To be confident that all of this works correctly, it is simply impossible to check every request by hand in a browser. This is exactly where Postman steps in. It is the most popular tool for testing, documenting and automating APIs, and it covers the entire range of work, from sending a simple GET request to wiring an entire test suite into a continuous integration pipeline.

In this article we will learn Postman from scratch. First we get familiar with the interface and basic requests, then we bring order to our work using collections and environments. After that we write JavaScript test scripts and learn to validate API responses automatically, and finally we automate the whole suite with the Collection Runner and Newman, plugging it into a continuous integration process. The material is equally useful for developers and testers alike.

What Postman Is and Why You Need It

Postman is a graphical environment for building and sending HTTP requests. While a browser conveniently sends only GET requests, Postman supports every method including POST, PUT, DELETE and PATCH, lets you configure headers and the request body precisely, and displays the response in a readable format. Most importantly, Postman saves every request, groups them into collections, and lets you share them with your team. This serves as a single source of truth for everyone working on an API.

The power of Postman lies in the fact that it is far more than a request sender. It lets you generate API documentation automatically, spin up a mock server, set up monitoring and, most importantly, write automated tests. For this reason, in many teams Postman becomes the central tool that manages the entire lifecycle of an API from design to operation.

Your First Request: GET and POST

After opening Postman you create a new request, choose a method and enter a URL. A simple GET request is used to retrieve data. For example, to fetch a list of users you send a request like the one below, and Postman shows the response as JSON:

GET https://api.example.com/v1/users
Accept: application/json

# Response:
{
  "data": [
    { "id": 1, "name": "Ali" },
    { "id": 2, "name": "Vali" }
  ]
}

A POST request is used to send new data to the server. To do this you go to the Body section, select the raw and JSON format, and write the payload you want to send. If authentication is required, in the Authorization section you choose a type such as Bearer Token or API Key. The following example shows creating a new user:

POST https://api.example.com/v1/users
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiI...

{
  "name": "Sardor",
  "email": "sardor@example.com"
}

Collections and Environments

Once you start working with several requests, you need a way to organize them. A collection is a set of related requests, for example a "Users API" or a "Payments API". Collections let you split requests into folders, attach descriptions to them and run the whole set at once. This is the main way to keep an API tidy and well structured.

An environment is a set of variables that lets you use the same collection under different conditions. For example, you might have "dev", "staging" and "production" environments, each with a different URL and token. Instead of hardcoded values, you use variables like {{base_url}} in your requests, and the moment you switch the environment, every request starts working with the new values:

// Environment variables:
base_url = https://api.example.com/v1
token    = eyJhbGciOiJIUzI1NiI...

// Using them in a request:
GET {{base_url}}/users
Authorization: Bearer {{token}}

Writing Tests: JavaScript Scripts

The most powerful side of Postman is the ability to attach test scripts to every request. These scripts are written in JavaScript and run automatically once a response to the request arrives. Test scripts verify that the response is correct: whether the status code matches what was expected, how long the response took, and whether the body contains the required fields. The example below shows simple tests checking the status code and the response structure:

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

pm.test("Response is faster than 500ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

pm.test("Response contains a data array", function () {
    const json = pm.response.json();
    pm.expect(json.data).to.be.an('array');
    pm.expect(json.data.length).to.be.above(0);
});

Test scripts do not only verify; they can also save variables for subsequent requests. For instance, a very common practice is to save the token returned from a login request into a variable and use it in the requests that follow. This lets you build chains of dependent requests:

// Extract and store the token from a login response:
const json = pm.response.json();
pm.environment.set("token", json.access_token);

// Now {{token}} works automatically in later requests

Automation: Collection Runner and Newman

Once several requests and their tests are ready, instead of running them one by one by hand you can run the whole collection automatically. The Collection Runner is a tool built into Postman that sends all the requests in a collection in sequence and shows the result of each test. You can even pull data from a CSV file and run a single request many times with different input values.

True automation, however, begins with Newman. Newman is a tool that runs Postman collections from the command line. It lets you run tests automatically after every code change, in other words plug them into a continuous integration (CI/CD) pipeline. The following example shows how to install Newman and run a collection:

# Install Newman:
npm install -g newman

# Run the collection with an environment:
newman run users-api.postman_collection.json \
  -e production.postman_environment.json \
  --reporters cli,json

You can place this command inside GitHub Actions or GitLab CI and ensure that API tests run automatically after every push. If any test fails, the pipeline stops and the team is notified immediately. This is the most reliable way to catch API regressions before they ever reach production.

Mock Servers and the Real Workflow

Sometimes the frontend team needs to start working without waiting for the API to be ready. Postman's mock server feature is designed for exactly this situation. You save the expected responses as examples in your collection, and Postman gives you a URL that mimics the real API. The frontend can work against this mock server, and once the real API is ready you simply swap out the URL.

The real workflow usually unfolds like this: a developer writes a new endpoint, tests it manually in Postman, then adds test scripts to it and saves it into a collection. A tester then extends that collection to cover edge cases. Finally, the entire collection is wired into the CI pipeline through Newman and runs automatically on every release. In this way Postman lets you manage the entire life of an API in a single tool, from the very first request to automated regression tests. This not only saves time but also keeps the quality of your API consistently high.