JSON to OpenAPI Response Schema Generator
Infer a response schema from JSON samples and generate one OpenAPI 3.0.3 YAML endpoint.
How it works
Paste a JSON response sample, enter a literal endpoint path, and choose GET, POST, PUT, or DELETE. The generator infers a response body schema and places it in an OpenAPI 3.0.3 YAML document.
Use representative samples to show the variations your response can contain. When several objects occur at the same array location, the generator combines their properties and marks a property required only when each observed object contains it.
Review the inferred types and required fields before using the YAML. Add request bodies, parameters, authentication, error responses, and any path parameter declarations yourself. Then validate the completed document with an OpenAPI validator.
Use this tool when JSON examples are available but a response schema is not. It only documents the selected path and method from the sample provided.
Step by step
- Paste a JSON response sample
- Set a literal path and choose the method
- Review and copy the response schema
Worked example
For GET /api/users, paste {"user":{"id":7,"name":"Ada"},"tags":["vip",null,7],"metrics":[{"count":2,"score":1.5},{"count":3,"active":true}]}. The sample contains nested objects, mixed array values, and two metric objects.
The output requires user, tags, and metrics. Both metric objects contain count, so it is required there. Score and active appear in only one object each, so they are optional. Tags accept a string or integer, and either observed type is nullable because the sample also contains null.
When to use this tool
Use the generator to turn example JSON response bodies into an initial OpenAPI response schema when documenting an endpoint.
It is useful for organizing observed response shapes. The generated document still needs the request, security, error, and parameter details required by your API.
Common mistakes
A single object makes every included property appear required. To identify properties that vary between responses, provide several objects in the same array location with representative differences.
Do not treat inferred output as a complete API definition. Check null handling, optional fields, array variants, and literal paths, then add request and error details that are outside this tool's scope.
Inference rules
For each object location, required keys = keys present in every observed object.
For each value, inferred schema = the union of observed non null types.
When null is observed with a known type, that typed schema is marked nullable.
This is sample based inference, not a runtime contract check. One example cannot establish which fields production responses may omit.
Limitations and assumptions
The result describes observed sample values. It cannot identify fields that are missing from every sample, prove that a field is optional in production, or infer an item type from an empty array. A null only value has no inferred type. Mixed values are represented as alternatives, which may need review against your API contract.
Key terms
- OpenAPI document
- An OpenAPI document describes an API's paths, operations, inputs, responses, and related details in a machine readable format.
- Schema
- A schema describes the expected structure and value types of data, such as an object with named properties.
- Required property
- In this output, required means the property appeared in every observed object at that location. It does not prove production behavior.
Compare related tools
Use YAML to JSON Converter when you need JSON from supported YAML input. Use SQL to TypeScript when you need TypeScript types from a table definition. This tool infers a response schema from JSON samples.
API Mock Generator creates mock rows from an example JSON object. This tool infers one response schema from a JSON sample and does not generate mock data.
FAQ
How does the sample become a response schema?
The generator inspects every value in the JSON sample. It creates object properties, examines all array items, and combines observed types with anyOf when needed. For example, the tags array in the worked example contains strings, null, and an integer, so its item schema allows a nullable string or a nullable integer.
How are nulls and different types represented?
Objects become schemas with properties. A property is marked required when it is present in every observed object at that location. Values with different observed types use anyOf. A property observed as null and another type gets nullable: true on the typed schema. A null only value has no inferred type, so its schema stays unconstrained.
What does the generated document include?
The document contains one path, the selected GET, POST, PUT, or DELETE method, and one successful 200 JSON response. Its schema is stored under components and referenced from the response. The generator does not create a request body, parameters, security rules, error responses, or headers.
Can I enter a path parameter such as an ID?
A path must be a literal path beginning with a slash, such as /api/users. Paths containing braces are rejected because a template such as /api/users/{id} also needs a declared path parameter, which this generator does not add.
Does this generate or validate a complete API contract?
No. The output describes a response body from an example. It does not infer request schemas or validate the generated YAML against the OpenAPI specification. Add other operations and response details yourself, then use an OpenAPI validator to check the completed document.
Related tools
YAML to JSON Converter converts supported YAML input to JSON. SQL to TypeScript derives type declarations from SQL structures. API Mock Generator creates mock rows from an example JSON object. This tool infers a response schema from JSON samples.