Inference from a single sample is a starting point, not a contract — check optional fields, nullable values and numeric bounds before shipping it. ⌘/Ctrl + Enter regenerates.
Writing a schema by hand for an existing API is tedious and error-prone. This infers one from a sample: types, nested objects, arrays, formats such as date-time, uuid and email, and closed sets of strings as enums. Array elements are merged rather than sampled, so the items schema describes every element — the union of their properties, with only the always-present keys marked required.
Pick the draft your tooling expects; the output is ready to drop into a repository.
Every element shapes the result, so optional keys stay optional instead of vanishing.
date-time, date, time, uuid, email, ipv4 and uri are recognised and annotated.
A string field that repeats a small set of values can be emitted as an enum.
Draft 2020-12 (the current one) and draft-07 (the one most tooling still targets).
A key is required only if it appears in every object of that shape in your sample. That is why feeding it an array with several varied elements gives a much better result than a single object.
Treat it as a first draft. Inference from one sample cannot know your real bounds, nullability or optionality — check those before shipping it, then test it against real payloads with the schema validator.