Run API tests using Postman Monitors

Postman Monitors provide a way to automatically run post-response scripts and perform tests at regular intervals. When you set up a monitor, you choose a collection with the requests and post-response scripts you want to run, and you specify how frequently Postman runs the collection. You'll be notified if a test fails, and all results are recorded on the monitor's dashboard.

Below are some ways you can use monitors to test your APIs and ensure they're functioning correctly.

For examples of monitors in action, visit the Postman API Monitoring Examples public workspace to find example collections for some common monitoring use cases. You can collaborate on the collections in the workspace by creating a fork, or modify the collections for your team's use by exporting and importing them into your internal workspace.

Monitoring an API endpoint

To monitor a specific endpoint, create a collection with different variants of the same endpoint in different requests to test responses for each variant and ensure complete test coverage. To learn more about testing requests, see Write scripts to test API response data in Postman.

Monitoring an entire API

This is similar in approach to monitoring a specific endpoint, with the subtle difference of storing the common API host in an environment variable, such that the requests across different API endpoints differ in their path, among other request parameters. Such a sequence also makes it possible to chain data across requests, which enables testing an entire API as a whole.

Running API tests

In an API where various endpoints are interlinked, precise knowledge about their functioning is crucial. In cases where data is passed from one request to another, the entire response, or a part of it, can be saved as an environment variable. Pay extra attention while setting non-atomic values (like objects and arrays), since the original value will be lost. Instead, such complex objects and arrays can be handled as follows:

// set the value
pm.environment.set('complexObj', JSON.stringify(myComplexObjOrArray, null, 2));

// get the value
var theValue;
try {
    theValue = JSON.parse(pm.environment.get('complexObj'));
}
catch (e) {
    console.error(e);
    theValue = { __parseError: true };
}
if (theValue.__parseError) {
    // handle parse errors here
}

With the stringified nested value in place, it can be passed to subsequent requests, for instance, as a request body.

Monitoring HTTP response codes

Response code tests can be done by checking the value within post-response scripts.

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

Monitoring latency

As an alternative to request timeouts, website response latency can be monitored within post-response scripts.

pm.test("Response latency is acceptable", function () {
    // responseTime is in milliseconds
    pm.expect(pm.response.responseTime).to.be.lte(1000);
});