Feature · API Testing

Turn "looks fine" into a test that actually runs.

Write pm.test() assertions in a post-response script and every future send checks itself — a broken response shows up as a red line in the results panel, not something you notice three requests later.

Start testing free See how it works

Why it matters

A regression you catch, not one you miss.

Three things automated assertions replace.

Independent checks, one script

Each pm.test() call is independent — one failing assertion doesn't stop the others from running, so a single response can carry several unrelated checks. Full pattern in the assertions reference.

A focused matcher set, not a maze

pm.expect() covers equality, type checks, membership, properties, numeric comparisons, and status codes — the common cases, chainable, with .not to negate any of them.

Results you can act on, not just a pass/fail count

Every run reports each test by name with a pass/fail indicator, its duration, and — for anything that failed — the actual error, so a request you've already verified stays verified on every future send. Ties directly into multi-request workflows.

See it in action

Write once, verify on every send.

A post-response script with independent assertions.

post-response.js

pm.test("Status is 200", () => {
  pm.expect(pm.response.status).to.equal(200)
})
 
pm.test("Response has a user id", () => {
  pm.expect(pm.response.json()).to.have.property("id")
})

3 passed · 1 failed · 38 ms

status is 200 PASS

response has a user id PASS

response is under 200ms PASS

response has cache-control header FAIL

FAQ

API Testing, answered.

The practical questions before you write your first assertion.

Is this a full assertion library like Chai?

No — pm.expect() supports a focused, chainable matcher set (equal, a, include, property, above/below, status), not the full Chai surface. There's no .deep.equal, .match() regex, or .length matcher; a plain JavaScript expression inside pm.test() covers anything those would normally handle.

What happens if one assertion fails — does the rest of the script stop?

No. Each pm.test() call is independent, so one failing assertion fails that test without stopping the others in the same script from running.

Where do I write assertions?

In a request's post-response script, wrapped in pm.test(). A couple of common checks (status, JSON content-type) also have shortcuts on pm.response.to.* that skip pm.expect() entirely.

What do I see when a test fails, beyond just 'failed'?

The results panel shows each test by name with a pass/fail indicator and duration, and for anything that failed, the actual assertion error — so you know exactly which check broke and why, not just that something did.

Talk to us.

Tell us about your team and what you're building. We'll get back to you.