Add assertions in the request’s Post-response script. Parse the response once, then test the HTTP status, the surrounding object, and the exact field value so failures explain what changed.
Last updated: October 13, 2026.
const body = pm.response.json();
pm.test('Response contains a ready order', () => {
pm.response.to.have.status(200);
pm.expect(body).to.be.an('object');
pm.expect(body).to.have.property('data').that.is.an('object');
pm.expect(body.data).to.have.property('status', 'ready');
pm.expect(body.data.id).to.be.a('string').and.not.empty;
});This example expects a response shaped like {"data":{"id":"A123","status":"ready"}}. Change the property path and expected value to match the API contract, not just one convenient sample response.
Test structure before the leaf value
Postman documents pm.test() and pm.expect() for named assertions. Verifying data before reading data.status produces a useful assertion failure instead of an unrelated JavaScript TypeError when the response shape changes.
Keep status, schema, and business-value checks separate when they represent different failure modes. A 200 response can still contain an application error, while a valid JSON error response may intentionally use 400 or 422.
Handle arrays, optional fields, and invalid JSON
For an array response, assert body is an array before using indexes or array assertions. Avoid relying on a fixed item position unless ordering is part of the contract. Test optional fields only when the condition that enables them is present.
pm.response.json() throws when the body is not valid JSON. First check the status and Content-Type when an HTML proxy error or empty response is possible. Postman’s official test examples also cover object inclusion, types, arrays, and environment variables.
Continue with fixing invalid UTF-8 in JSON, calling HTTP APIs from PHP, and preventing duplicate API operations.
