Every generator here does the same fundamental thing: look at one JSON sample and infer a typed model in some target language — TypeScript, Zod, Go, Python (dataclasses and Pydantic), Java, Rust, Kotlin, or C#. That's a genuinely useful shortcut for turning an API response you're already looking at into a type you can import, but it comes with a hard limitation worth internalizing before you rely on the output: inference from one sample can only see the types that sample happens to contain.

If a field is null in your sample but sometimes holds a string in production, every generator here will type it as strictly nullable and never as string | null unless the sample itself shows both. The same goes for arrays — an empty array gives no element type to infer, and a field entirely absent from the sample won't appear as an optional property, because there's no signal in a single document that it's supposed to exist elsewhere. None of the generators solve this by guessing; they generate exactly what the sample supports, which means the single highest-leverage thing you can do is paste a sample that's actually representative — a real response with every field populated, ideally from an edge case (a user with no avatar, an order with no discount) rather than the happiest path.

Beyond that shared constraint, each target has its own translation choices worth knowing: the Zod generator emits both the schema and the TypeScript type Zod would infer from it, so you get runtime validation and a static type from one input. The Go and Rust generators add the idiomatic tags each language's ecosystem expects — json:"..." struct tags in Go, #[derive(Serialize, Deserialize)] in Rust — rather than a bare struct with no serialization wiring. The Python tools split cleanly by use case: dataclasses for a lightweight typed container with no validation, Pydantic when you want the generated model to actually validate incoming data at runtime, matching the distinction those two libraries have in the Python ecosystem itself.