JSON to JSON Schema generator and validator

A generator sees values, not intent. It can tell that total held a number, that customer was an object with an id and an email, and that every item in the items array had a sku. It cannot tell that total must be positive, that status only ever takes four values, or that an order must contain at least one item. Those rules live in the API specification and the code, not in any one response.

Some types are guesses too. JSON makes no distinction between 1 and 1.0, so a price that happened to be a whole number in every sample is inferred as integer, and the first response with 19.95 in it then fails. Since draft-06 an integer in JSON Schema means any number with a zero fractional part, so the reverse is safe: a field typed number accepts 20. If a field is a decimal by nature, make sure at least one sample shows a fraction, or change integer to number by hand.

Formats are claimed conservatively. A string is only labelled date-time, date, email, uri, uuid or an IP address when every value seen at that place matches the format exactly, and a time must carry its offset, as RFC 3339 requires. A field that held "09:14:02" or "2026-10-26 09:14" stays a plain string.

With one sample, every key looks required and nothing looks nullable, because the generator has only ever seen each field filled in. Add a second response where coupon is null and the field becomes ["string", "null"]. Add a third without trackingUrl and that key drops out of required. Each extra sample from the same endpoint removes a false constraint.

The same merging happens inside arrays. The items of an array are described by one schema built from every item, so a key that only some items carry is optional, and a value that is a string in one item and null in another is nullable. Use Treat a top-level array as separate samples when you paste a list of whole responses and want the schema of one response, not of the list.

The three required settings answer different questions. In every sample is the honest default: a key is required when every object at that place had it. Every key seen describes a single complete example and will reject your other samples if they differ. None gives a type checker that never complains about a missing field, which suits early exploration but asserts very little.

For a schema generated from samples, the two drafts produce almost the same document: only the $schema URI changes, plus the uuid format, which draft-07 does not define, so in draft-07 a UUID becomes a pattern. The drafts differ more in what you might add by hand afterwards.

Choose by the tools that will read the schema. Postman’s pm.response.to.have.jsonSchema uses Ajv 6, which supports draft-07 but not 2020-12. REST Assured’s json-schema-validator module supports 2020-12 from version 6.1.0; earlier versions validated with draft-04 rules. Ajv 8 supports both, through a separate class for 2020-12, and Python’s jsonschema supports both.

A generated schema is a first draft of the contract, written from evidence that is necessarily incomplete. Before it guards a test suite, read it against the API documentation and tighten it where the samples could not.

Assertions on individual values check what a response says. A schema checks what a response is: every field present, of the right type, with nothing unexpected. One schema assertion catches a price that became a string, a field renamed in a refactor or a null where an object used to be, across every endpoint that returns that shape, without a line of assertion code per field.

Keep the schema next to the tests in version control, validate every response from the endpoint rather than one, and report all errors rather than the first: Ajv needs allErrors: true for that. When a schema assertion fails, decide whether the response or the schema is wrong before changing either, because updating the schema to match a broken response turns a defect into the contract.

Schema validation is not the whole contract test. It cannot say whether a value is correct, only whether it has the right shape, so pair it with assertions on the values that matter. Consumer-driven contract testing, such as with Pact, goes further by checking each consumer’s actual expectations against the provider.