Writing TypeScript types for an API response by hand is tedious. Paste a sample of the JSON and this tool writes the interfaces or type aliases for you. Nested objects get their own names, items in an array are merged into one shape, properties missing from some items become optional, and mixed values turn into unions.
How to use it
- Paste a sample of your JSON.
- Name the root type.
- Choose interface or type, and whether to export and use readonly.
- Copy the generated code into your project.
When it helps
- Typing an API response.
- Creating models for a configuration file.
- Starting a data model from sample data.
- Learning how JSON maps to TypeScript.
Good to know
- Use a sample that includes optional fields so they're detected; otherwise they'll be typed as required.
- A value that's always null in your sample is typed as null, so widen it if you know better.
- Treat the output as a first draft and rename things to suit your codebase.
How types are inferred
The tool walks through your JSON. Strings, numbers and booleans become the matching TypeScript types, null becomes null, and arrays become element types followed by square brackets. Each distinct object gets its own named interface, named after the property that contains it, in PascalCase.
When an array holds several objects, their properties are merged. A key missing from some objects becomes optional with a question mark, and a key with different value types becomes a union.
Worked example: a user record
A sample with an id, name, tags array, an address object and an array of orders yields a Root interface, an Address interface and an Order interface. The orders array shows an optional note property when one order has it and another doesn't.
You can then export the types and import them wherever you handle that data, getting autocomplete and compile-time checks.
Making the output production-ready
Rename generic names like Root to something meaningful, such as UserResponse. Replace union types with literal types where you know the allowed values. Mark fields readonly where appropriate. Review null: if a field can be a string in other responses, widen it.
For large or evolving APIs, generate types from an OpenAPI or JSON Schema specification instead, which is more complete than inferring from samples.
Keeping types in sync with the API
Types generated from a sample go stale when an API changes. Re-run the tool with a fresh sample when you see new fields, or validate responses at runtime with a schema library, so a mismatch is caught early rather than failing in production.
In larger teams, share types through a common package, or generate them from the API's published specification.
Questions
What about arrays of different object shapes?
They're merged into one interface with optional properties.
Is it accurate for every API?
It only knows what the sample shows, so give it a representative one.