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 collection-based 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 collection-based 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 team workspace.

Monitoring an API endpoint

To monitor a specific endpoint, create a collection with different variants of the same endpoint in different requests. The idea here is to test responses for each variant, so as to cover the endpoint completely. To learn more about testing requests, see Write API test scripts 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 allows 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
postman.setEnvironmentVariable('complexObj', JSON.stringify(myComplexObjOrArray, null, 2));

// Fetch the value
var foo;
try {
    foo = JSON.parse(postman.getEnvironmentVariable('complexObj'));
}
catch (e) {
    console.error(e);
    foo = { __parseError: true };
}
if (foo.__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 of responseCode.code within post-response scripts.

pm.test('Request resulted in 200 OK', () => pm.response.to.have.status(200));

Monitoring latency

As an alternative to request timeouts, website response latency can be monitored by comparing values of the responseTime variable within post-response scripts.

pm.test('Response latency is acceptable', () => pm.expect(pm.response.responseTime).to.be.lte(1000));
// responseTime is in milliseconds