Skip to main content
automationtester.in
Back to Blog
Tools & Reviews

Review Required Fields in a Generated JSON Schema

A schema inferred from one successful response may reject valid variants. Use the generator for observed types, then review required fields and closed-object rules against the API contract.

Shashank Rawlani

Engineering Leader | Builder | Problem Solver | AI Engineer

LinkedIn Portfolio
Published Oct 11, 2026Updated Oct 14, 20262 min read
View AI-ready Markdown
Three green field rows leave one sample object and enter a dashed schema box as required rows. A separate orange row, absent from the sample, stops at a crossed-out marker before the schema box.
Paste one representative JSON response into the JSON to Schema Generator to get a Draft 2020-12 starting point. Review required and additionalProperties before using it as a contract. One example cannot tell you which fields are optional across all valid responses.

A response from a successful request contains every field. A schema inferred from that one response may reject a perfectly valid response from an older account with no profile data. The generator can identify observed types; it cannot infer the API's full rules from one instance.

Generate from a small response

Open the tool, replace the sample with this JSON, leave “Required fields” checked, and leave “Allow additional properties” unchecked:

{"status":"paid","amount":499,"roles":["sdet"]}
Try this in JSON to Schema Generator

The generated object has status as a string, amount as an integer, and roles as an array of strings. It lists all three keys in required and sets additionalProperties to false. The $schema value names Draft 2020-12.

Those choices are visible decisions, not facts established by the sample. If roles can be omitted, remove it from required. If the API allows new response fields, turn on “Allow additional properties” or edit that rule after copying. JSON Schema defines required as property presence and additionalProperties as a rule for names outside those declared in properties.

Types are evidence; business rules need review

The observed string "paid" becomes {"type":"string"}. It does not become an enum, so the schema would also accept "unknown" unless you add an allowed-value rule. The number 499 becomes an integer, but the generator does not know whether negative amounts are forbidden or what unit the amount uses.

Array inference examines the elements it sees. An empty array gives the generator no item type to learn. Try a response with several valid shapes, then edit the schema against the actual API contract. JSON Diff can help find fields that changed across two captured responses, but neither tool replaces contract review. If the schema is headed for an MCP tool's outputSchema, paste the tool definition into the MCP Tool Schema Checker too; it reports required names that no longer match a property.

Does the generator validate my API? No. It produces a schema document from an example. Run that schema through a validator against separate positive and negative fixtures. When the JSON comes from a language model rather than an API, the reviewed schema can become a promptfoo is-json assertion; the LLM Eval Test-Case Builder writes it into the config as a mapping.

Should every observed field be required? Only if the contract says it must always appear. The checkbox expresses a starting assumption, not a discovery.

Review the contract before CI

Generate a schema from one real response. Mark every required field and closed-object rule that came from the sample alone. Check those decisions against the API specification or at least two contrasting fixtures before adding the schema to CI.

Schema specification and tool reference