Generating a TypeScript interface from a sample API response is genuinely useful and genuinely limited, and the limitation is worth understanding before you rely on the output. A single JSON sample tells you what one response looked like once. It does not tell you what the API guarantees, and a generator that treats the sample as a specification will produce a type that is wrong exactly where it matters.
The clearest case is a field whose sample value is null. A generator has to guess the real type from nothing, because null carries no structural information about what the field would otherwise contain. Some generators silently emit `null` as the type, which is rarely useful since nothing else can be assigned to it; the honest response is to flag the field as an advisory and let the author name the actual type from documentation or from a second sample.
Empty arrays and empty objects have the same problem in a different shape. An empty array reveals nothing about its element type, and a generator that defaults to `any[]` is making a silent decision it should instead surface. The same applies to an object with no properties in the sample — it might always be empty, or the sample might simply have caught it in an unpopulated state.
Optional versus required is a judgement call a single sample cannot settle either. A field present in one response and absent in another is clearly optional, but a field present in every sample you happened to collect is not proven required — it may simply not have come up yet. Marking every observed field as required produces a type that breaks the first time a legitimately absent field arrives.
The practical approach is to treat generated types as a draft that names its own uncertainty rather than a finished contract. A tool that lists every field it could not confidently infer — by path, with the reason — gives you something to check against real documentation or a second sample, instead of a type that looks complete and is quietly wrong.