Generate TypeScript interfaces directly on this page

Separate optional properties from nullable values

A property marked with a question mark may be absent, while a union with null says the key can exist with an empty value. Treating those cases as identical forces defensive checks into every consumer and makes API changes harder to reason about. Compare several payloads and the server documentation before finalizing either form.

With strictNullChecks enabled, this distinction becomes useful documentation. Components can handle genuinely optional data at the correct boundary instead of accepting broad types everywhere. When the backend owns a stable contract, prefer the narrowest accurate type rather than making all generated properties optional for convenience.

• Use property?: T when the key may be missing
• Use property: T | null when the key is present but nullable
• Use both only when the API actually permits both states

Refine arrays, literals, and dynamic keys

A populated array provides an element sample, but an empty array does not. Confirm the element contract before accepting unknown[] or any[]. Repeated string values such as status codes may become a literal union, while stable shared sets may deserve an enum or exported constant object.

Objects with unpredictable keys should usually become Record<string, T> or an index signature instead of a generated interface containing one sample key. Nested objects with stable shapes should receive descriptive names so that error messages, imports, and code review discussions remain understandable.

Keep transport types separate from UI state

A server response is not always the shape a React component should consume. Dates may be parsed, names may be combined, and nullable values may become display defaults. Mapping the generated response interface into a view model keeps presentation decisions out of the API client and prevents protocol changes from spreading across the component tree.

The same principle applies in Node services. Generated interfaces are useful for authoring and review, but network data is still untrusted at runtime. Zod, Valibot, JSON Schema, or another validator can enforce the contract before the value enters typed application code.

A practical verification workflow

Generate the interface from a representative payload, rename types around domain roles, and compare optional and nullable fields against real responses. Add a runtime schema at external boundaries when invalid data would cause meaningful failures. Then keep the payload fixture in tests so future server changes produce a visible diff.

This workflow preserves the speed of generation without pretending that one JSON example is a complete schema. The result is a contract that improves autocomplete, supports safe refactoring, and still acknowledges the uncertainty of data arriving from outside the TypeScript program.