Turn sample JSON into a draft contract your validators can enforce
JSON Schema is how teams document the shape of API bodies, configuration files and warehouse landing-zone records before code ships. Hand-writing schemas from scratch is slow and error-prone when you already have a golden sample from staging. This generator walks a parsed object tree, infers primitive types, common string formats, nested objects and array item shapes, then emits a Draft-07 or 2020-12 document you can paste into AJV, RapidJSON or your OpenAPI components section. Because generation is local, you can paste redacted production responses on a locked-down laptop without routing secrets through a third-party paste bin.
Schema workflow
- Paste a representative JSON object or array (one row is enough to start).
- Choose Draft-07 for compatibility or 2020-12 for newer tooling.
- Add an optional title so generated docs read well in a catalog.
- Copy the schema, then validate edge cases with the JSON Validator before you publish.
What the inferencer detects
Strings that look like dates, date-times, emails or URIs receive format hints when the pattern is unambiguous. Numbers distinguish integer versus floating representations based on the sample value. Nested objects recurse so deeply nested partner payloads become nested properties rather than opaque blobs. Arrays inherit the type of the first element — a reasonable default for tabular exports where every row shares columns. Required arrays list keys that appeared with concrete values in your paste so nullable fields you forgot to include do not silently become mandatory.
From sample to production contract
Treat generated output as a first draft, not law. Real APIs evolve: fields get deprecated, enums grow and one-of polymorphism rarely appears in a single sample. After generation, diff two environment samples in the JSON Diff tool, prettify readable fixtures with the JSON Formatter and validate tricky payloads in the JSON Validator before you check schemas into git. When configs arrive as YAML, convert with the YAML ⇄ JSON Converter first so the tree matches what your HTTP handlers actually parse.
Schema design habits that survive review
Prefer explicit additionalProperties decisions when you expose public APIs — inference may leave objects permissive compared to your security model. Document enums separately when only two values appeared in the sample but the product roadmap lists five. Keep examples alongside the schema in your repo so the next engineer can reproduce generation without guessing which paste was canonical. For XML-heavy partners, round-trip through the JSON ⇄ XML Converter only after the JSON side is stable; converting first and inferring second avoids mixed-namespace surprises.
From draft to an enforced contract
A schema only protects you once something checks against it. Wire the generated document into request validation with a library like AJV, into your OpenAPI components so the gateway rejects malformed bodies or into a data test that fails the build when a warehouse landing file drifts from its agreed shape. The generator gives you a permissive starting point, so tighten it before you enforce: set additionalProperties to false on public payloads, turn the two values you saw into a real enum and add min and max bounds where the business has them. An enforced schema turns a class of production surprises into a fast local failure on the pull request.