Docs / Testing

Assertions

Check a response automatically — status codes, values inside a JSON body, headers, timing and whole-body schemas.

An assertion turns a request into a test. Without one, a run tells you the request completed; with one, it tells you the response was right.

Adding an assertion#

Open the Assertions tab on a saved request.Press Add.
Pick a type.Status, JSONPath, header, response time, or JSON Schema.
Choose an operator and an expected value.For example type status, operator eq, expected 201.
Send the request.Each assertion is shown passed or failed, with what actually arrived next to what you expected.

Assertion types#

Type	Checks	Example
`status`	The response code	`status eq 201`
`jsonpath`	A value inside a JSON body	`$.data.id exists`
`header`	A response header	`content-type contains json`
`responseTime`	How long it took, in ms	`responseTime lt 500`
`jsonSchema`	The whole body against a schema	shape and types at once

Operators#

eq, ne, gt, gte, lt, lte, contains, matches (regular expression), exists, notExists, typeIs.

Checking inside a JSON body#

JSONPath addresses a value in the response. The path always starts at $, the root of the body.

$.id                    the top-level id
$.data.user.email       nested
$.items[0].name         the first item
$.items.length          how many came back

Send the request once and look at the body.Write the path against what actually came back, not what you expect it to be.
Start with exists before checking a value.$.data.id exists catches the field disappearing, which is the more common breakage.

Checking the shape with JSON Schema#

A schema assertion validates the entire body at once — every field, every type — which catches a number becoming a string, or an array becoming an object. That class of change breaks clients while every status-code check stays green.

{
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id":    { "type": "integer" },
    "email": { "type": "string" },
    "tags":  { "type": "array" }
  }
}

Where assertions run#

Everywhere the request runs: when you press Send, in a collection run, on a schedule from a monitor, and from the CLI. They are evaluated by the same code in each case, so a passing collection passes identically in CI.

A 200 is not automatically a pass

A request that returns 200 and fails an assertion is a failure. Collection runs and the CLI both exit non-zero for it, which is what makes them usable as a gate.

Frequently asked questions#

What is the difference between an assertion and a test script?

An assertion is declarative — pick a type, an operator and an expected value. A post-request script is JavaScript, for checks that need logic. Both appear together in the results, so use assertions unless you need code.

Can I assert on a value that changes every time?

Yes. Use exists to check the field is present, matches with a regular expression to check its shape, or typeIs to check its type, rather than eq against a value you cannot predict.