In a Postman test script, what does pm.response.to.have.jsonSchema(schema) assert, and what parses the body?

## The assertion and the engine behind it `jsonSchema` is a **chai assertion** that the Postman sandbox registers when it builds a script context. At initialisation the sandbox calls `chai.use(require('chai-postman')(sdk, _, Ajv))` — it *injects* the **Ajv** constructor into the plugin. Every `jsonSchema` call in a test script is therefore an Ajv validation wearing a chai face. That attribution matters in an interview: the keyword vocabulary a schema may use, the strictness applied to it, and the wording of each individual error are **Ajv's**, not Postman's. Postman contributes the chain, the auto-parse and the surrounding assertion message. The sandbox's own type declarations list two overloads under the `have` chain: ```javascript pm.response.to.have.jsonSchema(schema); pm.response.to.have.jsonSchema(schema, ajvOptions); ``` ## Two chains, and who does the parsing The same assertion is reachable two ways, and the difference between them is entirely about who turns bytes into an object. | Written as | Value validated | Who parses the JSON | |---|---|---| | `pm.response.to.have.jsonSchema(s)` | the reply body | the assertion, automatically | | `pm.expect(v).to.be.jsonSchema(s)` | `v`, exactly as handed in | you, before the call | `pm.expect` is chai's `expect`, so the second form accepts any value — a slice of a payload, an object you assembled, a value you already parsed with `pm.response.json()`. The first form is the convenience: hand it a schema and nothing else, and it takes the response, parses the body, and validates the resulting object. That auto-parse is the most useful thing about the response chain and the most common source of confusion: hand the assertion the **raw text** of a body instead and you are validating a string, so a schema describing an object simply fails. ## What one call covers - every field the schema names, at every depth, in one line; - a document you can review, diff and reuse across several requests; - new fields in the payload without a new assertion line; - a failure that names the offending path rather than a bare value mismatch. ## Negation and the failure text Both chains negate, and the negated form is a real assertion rather than a no-op: - `pm.response.to.not.have.jsonSchema(s)` passes when the parsed body does **not** satisfy `s`; - `pm.expect(v).to.not.be.jsonSchema(s)` is the same for an arbitrary value. The failure text is worth recognising in a run report: 1. a failed positive assertion reads `expected data to satisfy schema but found following errors:`, followed by one line per validation error — for example `data.alpha should be boolean`; 2. a failed negated assertion reads `expected data to not satisfy schema`, with no error list, because there were none to list. The word `data` in those messages is the validator's own name for the value under test. It is not a field in your payload, and candidates who read it as one usually go looking for a `data` wrapper that was never there. ## The second argument The declared second parameter is named `ajvOptions`. It is an options object for the validator sitting behind the assertion, which is the practical summary of the whole feature: when you tune this assertion you are tuning **Ajv**, not tuning Postman. Two consequences follow: 1. behaviour you already know from Ajv is the behaviour you get here — there is no Postman-specific dialect layered on top of it; 2. if two assertions in one script need different validator behaviour, each call carries its own options object; there is no collection-level place to set them once for the whole run. ## What a pass does and does not mean A green `jsonSchema` assertion means one thing precisely: **the value under test satisfied the schema object the script passed in, as judged by Ajv.** Everything else is inference, and each of these is a claim it does not make: - it is not a check against any published definition — the schema is a JavaScript object living in the script; - it does not assert that values are *correct*, only that they are shaped as the schema describes; - it has no opinion about anything the schema does not mention, so silence is not a failure; - it does not compare this release's shape against the previous one; a breaking-change gate over a published specification is a different tool's job. Against a hand-written per-field assertion set, the schema assertion buys breadth for one line, in a form somebody else can read. Against contract tooling, it buys nothing at all about *agreement between two parties*: it is a runtime shape check of one reply, in one run, against one document you happened to be holding. Saying which of those you are doing is the part of the answer that lands.