Why does a Ktor client call to body<User>() fail without ContentNegotiation installed?

## What the plugin does The Ktor client's response pipeline turns the received bytes into whatever type you asked for. Out of the box it can produce only low-level types: `ByteArray`, `String` (that is why `bodyAsText()` always works), and streaming types such as `ByteReadChannel`. When you write `response.body<User>()`, the pipeline looks for something that can transform the payload into `User`, finds nothing, and throws `NoTransformationFoundException`. The client `ContentNegotiation` plugin is what supplies those transformations. It holds a registry of `ContentType` → converter pairs, and it works in both directions: deserializing responses and serializing request bodies. ## Wiring it up Two dependencies are involved: `ktor-client-content-negotiation` for the plugin, and a serialization artifact such as `ktor-serialization-kotlinx-json` for the converter itself. With kotlinx.serialization you also need the Kotlin serialization compiler plugin and `@Serializable` on the model. val client = HttpClient(CIO) { install(ContentNegotiation) { json(Json { ignoreUnknownKeys = true }) } } The `json()` call registers the kotlinx JSON converter for `application/json`. Other converters (for example Jackson, or XML) register their own content types the same way, and several may be registered on one client. ## Receiving Once a converter is registered, `response.body<User>()` deserializes the payload. Which converter runs is decided by the **response's** `Content-Type` header. A server that answers `text/plain` with JSON-looking text will not be handled by the JSON converter, and you will get a transformation failure that looks identical to having no plugin at all — worth remembering when debugging. Customising the `Json` instance matters in practice: `ignoreUnknownKeys = true` is the difference between a client that survives a server adding a field and one that starts throwing. ## Sending On the request side, `setBody(user)` hands an arbitrary object to the pipeline. The plugin selects a converter using the request's `Content-Type`, so the content type must be set explicitly: client.post("https://api.example.com/users") { contentType(ContentType.Application.Json) setBody(User("ann", 30)) } Omitting `contentType(...)` is the single most common client-side mistake: there is no content type to match against, so no converter is chosen and the request body cannot be built. ## The Accept header A useful side effect of installing the plugin is that the client advertises what it can parse: registered content types are added to the outgoing `Accept` header. So a client with `json()` installed asks servers for JSON without you writing `accept(ContentType.Application.Json)` on every call. You can still set `accept(...)` per request when you need something narrower. ## The two ContentNegotiation classes Ktor ships two plugins with the same simple name: - `io.ktor.client.plugins.contentnegotiation.ContentNegotiation` - `io.ktor.server.plugins.contentnegotiation.ContentNegotiation` In a project that contains both a Ktor server and a Ktor client — very common — an IDE auto-import can silently pick the wrong one. The symptom is a client that still throws `NoTransformationFoundException` even though `install(ContentNegotiation)` is right there in the source. Checking the import is the first diagnostic step for that failure. ## Failure modes to recognise - `NoTransformationFoundException` on a typed `body<T>()` → no converter registered for that response content type, or the wrong plugin class imported. - A serialization exception naming an unexpected field → the server's payload does not match the model; `ignoreUnknownKeys` or a corrected model is the fix. - A request rejected by the server as an empty or malformed body → `setBody` used without `contentType(...)`. - A `@Serializable` annotation missing from the data class → a compile-time or runtime serializer error from kotlinx.serialization, not a Ktor error. ## Why it is worth knowing precisely This is the place where a Ktor client stops looking like a toy and starts looking like the transport layer of a real integration. The plugin decides how models cross the wire in both directions, and every one of the failure modes above is a debugging session someone loses an afternoon to. Knowing that the converter is selected by content type — on the response for reading, on the request for writing — explains all of them at once.