JSON to Types

The inference is the work; the printing is nine easy jobs

Most tools in this space do TypeScript and stop. The reason is not that the other eight languages are hard, it is that the shape inference is the whole of the difficulty and it is easy to under-build. Get it right once and every emitter after the first is an afternoon.

These are the rules, and each one exists because real API responses break the naive version:

• An array of objects is merged into one type. Typing from the first element is the default failure. If element one has an email and element two does not, the first-element approach gives you a type that lies about the second.
• A field missing from some elements becomes optional. That is the direct consequence of merging, and it is the single most useful thing this page tells you about a sample.
• A field that is null in some elements becomes nullable. Distinct from optional, and the distinction matters in every language here: string | null is not string | undefined.
• An integer and a float together are a float. 240 and 19.99 in the same field is a number, a float, an f64. Going the other way would silently truncate.
• Identical shapes reuse one type. Two nested objects with the same fields do not produce two identical interfaces with a numeric suffix.
• Nested types are named after their key, de-pluralized for array elements. A key called orders holding an array of objects produces a type called Order, not Orders or Root2.

The same sample, in the other eight

Each emitter follows its own language's conventions rather than transliterating the TypeScript.

# Pydantic
class User(BaseModel):
    id: int
    first_name: str
    email: Optional[str] = None
    balance: float

// Go
type User struct {
        ID         int64   `json:"id"`
        FirstName  string  `json:"first_name"`
        Email      *string `json:"email,omitempty"`
        Balance    float64 `json:"balance"`
}

// Rust
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct User {
    pub id: i64,
    pub first_name: String,
    pub email: Option<String>,
    pub balance: f64,
}

Go gets exported names with json tags carrying the original key and omitempty on the optional ones. Rust gets snake_case fields with a serde(rename) attribute wherever the JSON key differs. Pydantic gets snake_case with a Field(alias=…) where needed. Kotlin, Swift and C# get camelCase with their own mapping mechanism: Swift emits a CodingKeys enum, C# emits [JsonPropertyName] attributes. Zod emits a schema plus an inferred type, so you get validation and a type from one definition. Java emits a record.

The options, and when to change them

• Root type name names the top-level type. Nested types are named from their keys regardless, so this only affects the outermost one.
• Missing keys are optional is on by default and is the merging behavior described above. Turn it off when your sample is exhaustive and you want every field required, which is the right call when the sample is a fixture rather than a sample of production traffic.
• Export / public controls the visibility keyword: export in TypeScript and Zod, public in Java and C#, pub on Rust fields either way.
• Readonly properties adds readonly in TypeScript and uses let rather than var in Swift. Worth turning on for a type describing an API response, which nothing should be mutating.

A larger sample gives a better result, always. Two elements that differ tell the inference more than two hundred identical ones, so the most useful thing you can paste is a page of real responses rather than one hand-picked record.