In a saved Postman collection, what is info.schema, and where does a jsonSchema() assertion's schema come from?

juniorshould knowfreq 40%

answer

The same word means two different things
One meaning describes the file, not replies
It is required on the info block
The assertion's argument is built at run time

basics

~10 s

In a collection file, info.schema is a required string naming the collection format the file is written in, not a payload schema. A jsonSchema() assertion takes an object the test script itself builds.

solid answer

~40 s

Two unrelated things are called schema here. info.schema is a required string on the collection's info block, holding a URL that names the collection format the file conforms to — it is metadata about the file, and nothing validates a reply with it. The document a jsonSchema() assertion validates against is an ordinary JavaScript object produced by the test script: a literal written inline, a value read out of a variable, or something fetched during the run. The collection format has no field to hold one, so there is no link and no resolution step — what you validate against is a copy on your side, and keeping it in step with whatever the provider publishes is your job, not the file format's.

Two unrelated things are called schema here. `info.schema` is a **required** string on the collection's `info` block, holding a URL that names the collection format the file conforms to — it is metadata about the file, and nothing validates a reply with it. The document a `jsonSchema()` assertion validates against is an ordinary JavaScript object produced by the test script: a literal written inline, a value read out of a variable, or something fetched during the run. The collection format has no field to hold one, so there is no link and no resolution step — what you validate against is a **copy** on your side, and keeping it in step with whatever the provider publishes is your job, not the file format's.

code

javascript · 11 lines

javascript

// nothing in the collection file supplies this object;
// the script builds it and hands it to the assertion
const payloadSchema = {
    type: 'object',
    properties: {
        id: { type: 'string' },
        total: { type: 'number' }
    }
};

pm.response.to.have.jsonSchema(payloadSchema);

go deeper

for a junior

Recall that a collection file's info block carries a required schema string, that it names the collection format rather than any reply, and that the object you validate against is written in the script.

for a middle

Explain why the two meanings collide and what follows from the collection format having no home for a payload schema: every schema you assert against is a copy the script produces at run time.

for a senior

Show how you stop copies multiplying and going stale across a long-lived collection, and be honest in reporting about which document a green run actually validated the reply against.

for a principal

Decide where the authoritative shape definition lives for your organisation, and who owns keeping the copies inside collections in step with it as services change.

Two unrelated things called "schema"

A Postman collection file uses the word schema for something that has nothing to do with validating a reply, and that collision is the whole point of the question.

Where the word appears	What it actually holds
`info.schema` in the collection file	a URL naming the collection format the file itself is written in
the argument to `jsonSchema()`	a JSON Schema document describing a payload

info.schema is a required string on the collection's info block, sitting beside name. Its value is a link to the format definition the file conforms to — it is how a reader tells which generation of the collection format a given export was written in. It is metadata about the file. Nothing reads it to validate a response, and pointing it at a payload schema would produce a file no tool could load.

Where the validated schema actually comes from

jsonSchema(schema) takes a JavaScript object, evaluated in the script at the moment of the call. The collection format offers no home for such a document: its top-level keys cover the collection's metadata, its items, its scripts, its variables, its auth and its per-request behaviour, and none of them is a place to park a JSON Schema. So the object has to be produced by the script itself. In practice that means one of:

a literal written inline in the test script, next to the assertion that uses it;
a value the script reads out of a variable it can see, then parses if it was stored as a string;
a document the script fetches during the run and holds in memory for the assertion.

Each of those is a copy. There is no reference, no link, and no resolution step that reaches out to an authoritative definition on your behalf.

Why interviewers ask this

The question separates people who have written a schema assertion from people who have only read about one. The mental model that fails is "the collection knows my schema" — a belief that because the file has a field called schema, and because the assertion is called jsonSchema, the two are wired together. They are not. Consequences of getting this wrong:

Duplication. Paste the same schema into eight requests and you now maintain eight copies that drift apart silently.
Invisible staleness. The provider adds a field or tightens a type; nothing in the collection notices, because nothing in the collection points at the provider's definition.
False confidence. A green run proves the reply matched the copy in the script, which is a much weaker statement than "the reply matched the published definition".

Practical shape of a script that does this well

keep the schema in one place per payload rather than one place per request, so a change is one edit;
treat the schema as a reviewable document — it is data, and it reads like data, so a reviewer can actually check it;
if the schema is stored as a string somewhere, parse it once and reuse the parsed object, rather than parsing per assertion;
do not conflate the copy in the script with the provider's definition when you report results; say which one you validated against.

The line to say out loud

The compact answer is two sentences. info.schema is a required string in the collection file that names the collection format, not a payload schema. The schema that jsonSchema() validates against is an ordinary object built by the script, so keeping it in step with whatever the provider actually publishes is your problem, not the file format's.

## Two unrelated things called "schema" A Postman collection file uses the word `schema` for something that has nothing to do with validating a reply, and that collision is the whole point of the question. | Where the word appears | What it actually holds | |---|---| | `info.schema` in the collection file | a URL naming the **collection format** the file itself is written in | | the argument to `jsonSchema()` | a **JSON Schema document** describing a payload | `info.schema` is a **required** string on the collection's `info` block, sitting beside `name`. Its value is a link to the format definition the file conforms to — it is how a reader tells which generation of the collection format a given export was written in. It is metadata about the file. Nothing reads it to validate a response, and pointing it at a payload schema would produce a file no tool could load. ## Where the validated schema actually comes from `jsonSchema(schema)` takes a **JavaScript object**, evaluated in the script at the moment of the call. The collection format offers no home for such a document: its top-level keys cover the collection's metadata, its items, its scripts, its variables, its auth and its per-request behaviour, and none of them is a place to park a JSON Schema. So the object has to be produced by the script itself. In practice that means one of: - a **literal** written inline in the test script, next to the assertion that uses it; - a value the script **reads out of a variable** it can see, then parses if it was stored as a string; - a document the script **fetches** during the run and holds in memory for the assertion. Each of those is a copy. There is no reference, no link, and no resolution step that reaches out to an authoritative definition on your behalf. ## Why interviewers ask this The question separates people who have written a schema assertion from people who have only read about one. The mental model that fails is *"the collection knows my schema"* — a belief that because the file has a field called `schema`, and because the assertion is called `jsonSchema`, the two are wired together. They are not. Consequences of getting this wrong: 1. **Duplication.** Paste the same schema into eight requests and you now maintain eight copies that drift apart silently. 2. **Invisible staleness.** The provider adds a field or tightens a type; nothing in the collection notices, because nothing in the collection points at the provider's definition. 3. **False confidence.** A green run proves the reply matched *the copy in the script*, which is a much weaker statement than "the reply matched the published definition". ## Practical shape of a script that does this well - keep the schema in **one** place per payload rather than one place per request, so a change is one edit; - treat the schema as a reviewable document — it is data, and it reads like data, so a reviewer can actually check it; - if the schema is stored as a string somewhere, parse it once and reuse the parsed object, rather than parsing per assertion; - do not conflate the copy in the script with the provider's definition when you report results; say which one you validated against. ## The line to say out loud The compact answer is two sentences. `info.schema` is a required string in the collection file that names the collection format, not a payload schema. The schema that `jsonSchema()` validates against is an ordinary object built by the script, so keeping it in step with whatever the provider actually publishes is your problem, not the file format's.

If eight requests each validate the same payload, what goes wrong with a pasted schema literal?
You now maintain eight copies that drift apart. Three get updated when the payload changes and five do not, so some requests silently police an old shape. Keep one copy per payload rather than one per request, so a change is a single edit that every assertion picks up.
Does anything in a Postman run fetch the definition named by info.schema and validate replies with it?
No. That URL names the collection format the file is written in — it identifies which generation of the format a reader is looking at. No part of a run resolves it to validate a response, and pointing it at a payload schema would produce a file no tool could load.

saying these in an interview costs you the question

Says info.schema holds the schema replies are validated against
Expects the runner to fetch a schema automatically each run
Thinks the collection format has a field for a payload schema
Treats a green run as proof against the published definition
Pastes the same schema literal into every request that needs it

In a saved Postman collection, what is info.schema, and where does a jsonSchema() assertion's schema come from?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

Two unrelated things called "schema"

Where the validated schema actually comes from

Why interviewers ask this

Practical shape of a script that does this well

The line to say out loud

▾common follow-ups2 questions

▾red flags5 flags

Two unrelated things called "schema"

Where the validated schema actually comes from

Why interviewers ask this

Practical shape of a script that does this well

The line to say out loud

answer

go deeper