Automating API Tests in Postman

Postman's manual request workflow is fine for one-off checks, but the real payoff comes when you encode assertions that run every time you hit an endpoint. Those tests catch regressions early and let you add features without fear of silently breaking an existing route. Here is a repeatable process for turning any Postman request into an automated test, using a fictional property-listing service as the example.

Why Bother Writing Tests

Automated tests are a quality gate. When an API backs a single frontend or a dozen downstream consumers, you need confidence that each endpoint behaves as expected. Running the same assertions on every request makes regressions obvious the moment they appear. That speed matters: if you can run a quick test suite before shipping a change, you spend less time debugging and more time building.

A Four-Step Test Workflow

You can apply the same sequence to every endpoint you want to cover:

  1. Send the request manually to see what the API actually returns.
  2. Study the response — status code, body shape, and any fields you care about.
  3. Write test scripts in the Tests tab of that request.
  4. Repeat for every other endpoint in the collection.

The demo service exposes four routes: a home endpoint at /, user signup and signin at /user/signup and /user/signin, and a protected listing creator at /listing/new. You can import these into your own workspace to follow along.

Start With a Manual Request

Open the home request in the collection and press send. The response should come back with a 200 OK status and a JSON body containing a message field set to "You have reached postman test demo web service". That is your baseline: any assertion you write must match this observed behavior.

Write and Run the First Test

Postman runs JavaScript in two phases per request. Pre-request Scripts execute before the call is sent; Test scripts run after the response arrives. Test scripts are what you want for assertions. Open the Tests tab and pick the Status code: Code is 200 snippet from the right-hand panel. It generates:

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

Every Postman test begins with the test() function exposed on the pm global object. The first argument is a human-readable description; the second is a callback containing your assertion. You can chain multiple assertions inside one test, but keeping each check in its own test makes failures easier to read.

Send the request again. Postman evaluates the script after the response arrives and shows the result under the Test Results tab. A passing test is good, but you should see it fail first. Add a stray /a to the URL and send again — a 404 status makes the assertion fail, confirming the test is actually tied to the response and not passing for some unrelated reason. Remove the suffix and the test passes again.

Now add a second assertion to verify the body. This test parses the JSON response and checks the value of message:

pm.test("Contains a message property", function() {
    let jsonData = pm.response.json();
    pm.expect(jsonData.message).to.eql("You have reached postman test demo web service");
})

That covers the home route. Move on to the next endpoint and repeat the same loop.

Signup: Check Status, Type, and Token

The signup route is a POST request that expects fullName, emailAddress, and password as form-encoded fields in the Body tab. First make the request manually so you can see the response. A successful signup returns a 201 Created status and includes a token property in the body.

Write your tests to lock down those observations:

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

pm.test("Response has a JSON body", function () {
    pm.response.to.be.json;
});

pm.test("Response has a token property", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.token).to.be.a('string');
});

From top to bottom, you are asserting that the response status is 201, that the body parses as JSON, and that token exists and is a string. One practical note: the service rejects duplicate emails, so change the address if you run this more than once. All three tests pass on a fresh request.

Signin: Same Shape, Different Credentials

The signin endpoint behaves almost identically — send the emailAddress and password of an existing user and you get back a token. Add the meaningful assertions to the Tests tab:

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

pm.test("Response has a JSON body", function () {
    pm.response.to.be.json;
});

pm.test("Response has a token property", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.token).to.be.a('string');
});

pm.test("Response has a data property", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.data).to.be.a('object');
});

Use credentials you created during the signup step. The response status will differ from signup — a 200 OK rather than 201 — so keep your status assertion aligned with the actual endpoint contract.

Listing Creation Needs Authentication

The last endpoint, /listing/new, is protected: only a signed-in user can create a listing. This demonstrates how to inject state into a test. Copy the token returned by the signin request and open the Authorization tab for the listing request. Set the type to Bearer Token and paste the token into the Token field.

The Body tab already contains sample field names and values for the listing itself; you can keep or edit them. Make the request to see the expected response shape — a JSON body confirming the new listing. Then assert on what you saw:

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

pm.test("Response has a JSON body", function () {
    pm.response.to.be.json;
});

pm.test("Response has a message property", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.message).to.be.a('string');
});

pm.test("Response has a data property", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.data).to.be.a('object');
});

This test verifies the response really is JSON and that data is not empty. Send the request again and all assertions pass.

Rinse and Repeat

You now have a scripted check for each of the four endpoints. The pattern is the same every time: hit the route once manually, note the status and the body, translate those observations into pm.test assertions, and move on. After the first route, each additional endpoint takes minutes rather than hours.

These tests run whenever you send the request from Postman, which means your own manual workflow is already an automated smoke test. Expand from here — checking response times, validating schemas, or testing edge cases — and you have a lightweight regression suite that lives next to your API collection.