A JSON Schema lets a Postman test compare a response body against a strict, structural contract in one assertion instead of dozens of property checks. To create JSON Schema in Postman from a real response, the fastest path is to feed that response into a Draft 2020-12 generator, inspect the inferred required fields, nullability, and arrays, then paste the resulting schema into a Postman test script. The generator never contacts a registry, runs a validator, or uploads the sample, so the workflow stays predictable during API work. Postman tests built on Draft 2020-12 will accept a well-formed schema and surface every mismatch in the test results panel, which is why most teams now skip handwritten schemas and start from a generator. This approach also keeps the schema text stable across versions, because the generator is deterministic for the same input.
This guide covers what the JSON Schema Generator inspects, how to turn a Postman response sample into a Draft 2020-12 schema in three steps, and how to read the output before you commit it to a Postman test. It also walks through the exact context Postman users actually need: a section with concrete steps for plugging the generated schema into a Postman request test. The target dialect URI is https://json-schema.org/draft/2020-12/schema, and you should confirm that your validator of choice supports that dialect before relying on its assertions.
What a Draft 2020-12 Schema Adds to a Postman Test
A Postman test script is JavaScript that runs after a request completes. Without a schema, you assert one field at a time with pm.response.json() and hard-coded checks. With a schema, you assert shape, type, and presence in one call. The schema is plain text, lives in a Postman environment variable or a Collection-level variable, and travels with your requests through the Collection Runner and CI runs.
Draft 2020-12 is the dialect the JSON Schema Generator emits. Postman ships with tv4 (Tiny Validator for JSON Schema) bundled in older versions, and modern Postman test scripts can call ajv, which supports Draft 2020-12 when configured. The dialect matters because some keywords introduced after Draft 4 behave differently, and the generator's open-object policy only makes sense when paired with a validator that honors missing additionalProperties as "allow".
What the Generator Inspects From a Response Sample
The generator parses one strict JSON value and walks it recursively. JSON strings, safe integers, other numbers, Booleans, and null each map to their corresponding JSON Schema types. Arrays emit an items schema inferred from every observed element, and empty arrays produce an empty items schema because no element constraint can be justified. When two compatible number types appear together, the generator widens integer to number; when the types are incompatible, it falls back to a deterministic anyOf branch so the schema still accepts both shapes.
Objects emit type, properties, and required. A property observed in every merged object sample is added to the required array. A property missing from at least one object is omitted from required, even if it appears in most samples. The generator preserves property names exactly, including punctuation and prototype-shaped spellings, so what you paste is what you get. Crucially, the generator intentionally omits additionalProperties, leaving objects open. One sample cannot prove that unseen keys are forbidden, so the schema accepts them until your authoritative contract says otherwise.
What the generator deliberately does not do is just as important. It does not infer format, pattern, enum, const, minimum, maximum, multipleOf, length, uniqueness, descriptions, defaults, examples, deprecation, readOnly, writeOnly, content encoding, references, anchors, IDs, conditional logic, unevaluated properties, or business meaning. Add those only from documented requirements. The page treats this as structural sample inference, not schema discovery.
| Observed in the Postman sample | Inferred keyword | What the generator emits |
|---|---|---|
| String value | type | "string" |
| Safe integer | type | "integer" |
| Other number (float, large integer) | type | "number" |
| Boolean | type | "boolean" |
| null combined with a typed schema | type | type array includes "null" alongside the original type |
| Mixed compatible numbers (integer + number) | type widening | "number" |
| Incompatible types in same slot | anyOf | deterministic anyOf branch per type |
| Array with observed elements | items | items schema inferred from each element |
| Empty array | items | empty schema |
| Property in every merged object | required | property added to required array |
| Property missing from any object | (omitted) | not added to required |
| Object of any size | type, properties, required | object schema with open additionalProperties |
Generate the Schema From a Postman Response Sample
This is the core workflow. Open the JSON Schema Generator, paste a representative response captured from Postman, and inspect the result.
- Capture a strict JSON response from Postman. Send the request, then copy the response body from the Body tab. Make sure the JSON is strict: no comments, no trailing commas, no NaN or Infinity. If the response looks messy, format it first with the JSON Formatter so the generator parses the same shape Postman will see at test time.
- Open the JSON Schema Generator and paste the sample. The page parses the JSON in your current tab; nothing is uploaded. Optionally enter a concise schema title in the title field. Pick a representative sample rather than the first response you see — if your endpoint sometimes returns a richer object, paste the richest sample you want the schema to accept.
- Generate and inspect the schema. Click generate. Review the output for required fields, nullability on direct-typed schemas, array items inferred from observed elements, and anyOf branches where the sample mixed incompatible types. Empty arrays produce an empty items schema, and nullable properties produce a type array that includes null.
- Copy the schema text. Use the copy control on the page. The output is deterministic for the same input, so you can paste it into version control and rerun the generator later to confirm nothing has drifted.
- Validate against positive and negative instances. Before you commit the schema to Postman, run it through a Draft 2020-12-capable production validator with one accepted instance and one rejected instance. The JSON Schema Generator does not run validators and does not contact a registry; that step is yours.
Wire the Generated Schema Into a Postman Test
Postman reads the schema as a string and passes it to a validator inside the Tests tab. The exact validator you choose determines which Draft 2020-12 keywords it enforces, so pick the same library you intend to ship to production and use it here too.
- Save the schema as a Postman variable. In the Collection or request, open Variables and add a variable called responseSchema. Paste the schema text into the Current Value field, or store the schema as a file in your repo and load it with pm.collectionVariables.set in a pre-request script. The variable approach lets the Collection Runner reuse the same schema across environments.
- Add the validator to the Tests tab. Postman ships with tv4 for older Draft 4 schemas. For Draft 2020-12, prefer ajv through a sandbox or a vendored bundle: pm.sendRequest the library once per run, or include it via a local copy. The exact code path depends on your runner configuration, but the contract is the same: load the validator, parse the schema string, parse the response, and compare.
- Assert and surface failures. Use pm.expect or the tv4 result object to fail the test when validation reports errors. Capture the validator's error list with JSON.stringify so the failure message in the Postman runner points at the exact property path. That single message replaces the dozen pm.response.to.have.property checks the test would otherwise need.
- Run the request against a known-good response. Send the request once and confirm the test passes. Then send it against a deliberately broken response (remove a required field, change a type) and confirm the test fails with a clear message. Both directions matter; a schema that never fails is not a contract, it is decoration.
Read the Output Before You Paste It Into Postman
The generated schema is readable and reviewable, and that is the point. Look for four things before you ship it.
Required fields should match what your authoritative contract promises. The generator declares required from presence in the merged sample, so if you only pasted one response, required reflects that one response. If you paste a richer sample, required widens. If a property is intentionally optional in production but appears in every sample you have, the generator will mark it required and your test will fail the first time a real client omits it.
Nullable values appear as a type array that includes null. A property typed as null combined with a directly typed schema adds null to the type array while keeping properties or items intact. More complex combinations, such as a property that is sometimes a string and sometimes null with different shapes, fall back to anyOf.
Array items reflect every observed element type. If your array mixed numbers and strings, you will see an anyOf branch over both. Empty arrays leave items as an empty schema, which Postman will interpret as accepting anything — that is intentional, because no element constraint can be justified.
Open objects stay open. The schema does not include additionalProperties: false, so Postman accepts new keys. Add the closed-object keyword from your authoritative contract if you want Postman to reject unknown keys.
Validate the Schema With the Same Validator Postman Uses
The JSON Schema Generator emits text and stops. It does not run a validator, does not guarantee format assertions, and does not contact a schema registry. Validators interpret keywords differently across libraries, and Draft 2020-12 format behavior is annotation-only unless the chosen implementation enables assertion. Before you publish the schema, run the same schema through the same validator Postman will use, with both an accepted and a rejected instance. The JSON Schema core specification is the source of truth for what each keyword means; if your validator disagrees, your validator needs tuning, not your schema.
The JSON Schema Generator page keeps parsing and inference local to your tab, so the schema you copy is exactly the schema you will paste into Postman. The limits you should keep in mind are 500,000 input characters, 50,000 values, 40 nesting levels, and 1,000,000 output characters. Boundary failures emit no partial schema, so if your response sample is unusually large or nested, trim it or break it into smaller schemas rather than rely on the tool to recover.
Edge Cases That Break the First Postman Validation
A few failure modes show up the first time teams adopt this workflow. The schema passes in Postman but fails in production because the production validator uses a different ajv configuration — fix by testing the same schema through the same validator in both places. The schema fails because Postman returned the response as a string and you forgot JSON.parse before validation — fix by parsing once at the top of the Tests tab. The schema fails because Postman dropped a property on serialization — fix by validating the raw response before any Postman-side reshaping.
Strict JSON is required by the generator, so comments, trailing commas, NaN, Infinity, undefined, BigInt, and JavaScript literals all fail. JavaScript parses the sample number before inference; only safe integers become integer, which avoids a false exactness claim for larger rounded values. Precision-sensitive decimals and identifiers should travel as strings plus application validation, not as JSON numbers the generator will type as integer or number.
If the body captured from Postman is hard to read at a glance, format the response sample for readability before you paste it. That guide covers indentation choices and quick sanity checks that line up with what the generator expects to parse, and it avoids surprises when the validator in Postman later rejects a subtle malformed value.