Postman is the tool most testers meet first when they start working with APIs. It began as a simple way to fire off HTTP requests and read the response, and it grew into a full workbench for building requests, saving them in collections, storing environment variables and writing assertions in JavaScript. You can click your way through it, but everything you build can also run headless in a pipeline, which is what makes it useful for automation and not only for manual poking.
How it works
You organise requests into a collection. Each request has a method, a URL, headers and a body. Postman lets you attach small scripts to a request. A pre-request script runs before the call goes out, and a test script runs after the response comes back. The test script is where you assert, using the built in pm object:
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
pm.test("Check if access_token exists in response body", function () {
let jsonData = pm.response.json();
pm.expect(jsonData).to.have.property('access_token');
});
Variables tie it together. A login request can read access_token from the response and store it, and a later request can send it as a Bearer header. That is how you chain an authenticated flow without hard coding secrets into every call.
To run a collection outside the app you use Newman, the Postman command line runner. Newman runs the same collection file, prints the results and can produce an HTML report through the htmlextra reporter. Because the collection is a JSON file, it lives in Git next to your code and runs in CI like any other test.
Benefits
The learning curve is gentle. A tester who has never automated anything can build a working request and a first assertion in minutes. The graphical view makes it easy to inspect headers, cookies and timings while you explore an API. Collections are shareable, and the same file works both for a person clicking through it and for Newman running it on a schedule.
Downsides
Assertions live inside a JSON collection, so version control diffs are noisy and code review is awkward. Larger suites become hard to structure because there is no real module system, only folders and copy pasted snippets. Some collaboration features sit behind a paid plan, and the desktop app has grown heavy over the years. For a big regression suite many teams eventually move the logic into a proper programming language and keep Postman for exploration.
What the example project tests
The repository at github.com/testsmith-io/api-test-automation-postman tests the Practice Software Testing API at https://api.practicesoftwaretesting.com, a ToolShop style e-commerce backend. The base URL is stored as a collection variable, and three scenarios are covered.
The first requests GET /brands and checks that the call returns status 200 with at least two brands in the array. The second sends POST /users/login with a known customer email and password and asserts that the response is 200 and contains an access_token. The third is the interesting one, because it chains two calls: it logs in, stores the token, then calls the protected GET /invoices endpoint with an Authorization: Bearer header and checks the returned list of invoices.
A GitHub Actions workflow runs the collection with Newman on every push and on a weekly schedule, then uploads the HTML report as an artifact. It is a small suite on purpose. The point is to show the same three scenarios in a tool many people already have open, so you can compare it fairly against every other approach in this series.