Empty arrays hide their element type

An array in your sample may simply be empty: "tags": []. There is nothing there to infer from, so the generator emits unknown[] — an array of anything.

This is honest but not useful, and worse, it is quiet: when real data arrives full of objects, nothing in your editor warns you that you are reaching for a field the type never described. Fill the element type in by hand from the API documentation — change unknown[] to Tag[] and define Tag yourself — or, better, find a sample response where the array actually has items in it and regenerate.

A null value tells you less than it appears to

When a field is null in the sample, the generator types it as null and marks it optional with ?. That reflects the sample accurately, but it conflates two different facts that the sample cannot separate: whether the field is always present but sometimes null, or whether it is sometimes absent altogether.

The generated maybeAuthor?: null claims the field may be missing and, when present, is only ever null — which is almost never what the API actually means. If it is always sent and merely nullable, drop the ? and widen the type to Author | null. This one-line correction is the most common fix you will make to a generated interface.

Optional fields are invisible when the sample is complete

The mirror image of the problem above, and the reason a generated type gives false confidence. If your sample response happens to include every field, everything is generated as required. A field the API omits when empty is typed as always present, and the compiler will then happily let you read it with no check at all — producing exactly the runtime undefined error that having types was supposed to prevent.

Generate from the largest, most representative response you can obtain, then go through the result marking genuinely optional fields with ?. The generator saves you the transcription; it cannot do the judgement.

Nested objects, unions and key naming

An object inside an object becomes its own interface, named by converting the property name to PascalCase — author_info produces export interface AuthorInfo — so identical shapes appearing in several places collapse to one definition.

Arrays whose elements differ generate a union, such as (string | number)[]. That describes the sample faithfully, but one sample cannot show every variant the API might send, so widen it by hand where you know more than the sample does.

Property names that are valid JavaScript identifiers appear as-is. Anything else — a name with a hyphen, or one starting with a digit — is emitted as a quoted key, so my-prop becomes "my-prop": string; inside the interface. If the root of your JSON is an array or a primitive rather than an object, you get a type alias instead of an interface: export type Root = string[];

Types vanish at runtime

These are structural types checked at compile time and erased entirely when the code runs. A generated interface does not validate anything — it is an assertion about data you have not inspected, and if the API changes shape your program will fail exactly as it would have without types, just later and more confusingly.

Where the data genuinely cannot be trusted, a runtime validation library such as Zod or Valibot is the answer, checking the response as it arrives. A generated interface and a runtime validator solve different problems, and neither substitutes for the other.

See also: cURL to Fetch, JSON to Go Struct, and Query String to JSON.