@SerialName und benutzerdefiniertes Field-Mapping

Real APIs love keys like user_name, but Kotlin prefers userName. @SerialName lets the two disagree peacefully.

Put @SerialName above a property to tell the serializer which JSON key it really maps to.

Your code keeps clean camelCase names while the wire format keeps whatever the backend chose. Both sides win.

Many JSON APIs use snake_case, so mapping created_at to a createdAt property is one of the most frequent uses.

If JSON has a key like type that clashes with your style, @SerialName frees you to name the property whatever reads best.

You can annotate as many properties as you like, mixing renamed and default-named fields inside the same data class.

@SerialName also works on enum constants, so an ACTIVE entry can serialize as the lowercase string the API expects.

If every key is snake_case you can set a JsonNamingStrategy once instead of annotating each field by hand.

When both a global strategy and an explicit @SerialName apply, the annotation takes priority for that one field.

The custom names apply to both encoding and decoding, so one annotated model handles reading and writing JSON.

Mapping keys explicitly means a backend rename only touches one annotation, not your whole codebase.

How do you map a JSON key to a differently named Kotlin property?

Use @SerialName to map mismatched JSON keys to idiomatic Kotlin names on fields and enums, or set a global naming strategy for whole models.