Which approach best handles field-level error reporting with Request Validation?

The recommended pattern is: collect all failures inside the validate block into a structured error model, surface them through the validation exception, and let a StatusPages handler serialize that model into a 400 response. There is no annotation-based magic in Ktor's Request Validation plugin — you own both the error shape and the mapping.

Define an error model and return it from validate

Start with a serializable model, for example:

@Serializable
data class FieldError(val field: String, val message: String)

@Serializable
data class ValidationErrors(val errors: List<FieldError>)

In the validate block, accumulate every failure rather than stopping at the first one. With Ktor's ValidationResult, the idiomatic approach is to return ValidationResult.Invalid(reasons) where the reasons encode your field-level detail. When validation fails, Ktor throws a RequestValidationException carrying those reasons. One important caveat: in the Ktor versions I can speak to confidently, RequestValidationException exposes the failure detail as a list of reason strings rather than an arbitrary typed payload. If you need structured data rather than strings, two common workarounds exist:

• Encode each failure as a string like "email: must be a valid address" and split on the delimiter in the handler — simple but brittle.
• Skip the plugin's exception path for complex cases and throw your own exception type (e.g., class FieldValidationException(val errors: ValidationErrors) : RuntimeException()) from inside the validate block, then map that type in StatusPages. This gives you a fully typed payload.

The second option is the cleaner pattern when you genuinely need a JSON array of field/message pairs, and it composes fine with Request Validation for the simple cases.

Map the exception in StatusPages

install(StatusPages) {
    exception<FieldValidationException> { call, cause ->
        call.respond(HttpStatusCode.BadRequest, cause.errors)
    }
    exception<RequestValidationException> { call, cause ->
        call.respond(HttpStatusCode.BadRequest, mapOf("errors" to cause.reasons))
    }
}

Because these exceptions are unchecked, they propagate through the pipeline to StatusPages — no try/catch is needed in your routes. Install both plugins at the application level; the exact property name on RequestValidationException (e.g., reasons) varies slightly across Ktor 2.x/3.x, so check the API reference for your version.

Watch for two failure modes

1. Generic fallback: if the exception reaches StatusPages without your detail attached (or you only map Throwable), clients get a bare 400 with no field information.
2. Handler shadowing: a broad exception<Throwable> or exception<Exception> mapping registered before the specific one can intercept the exception first. Register specific handlers and keep the catch-all last, or omit it.

Verify

Send a request with multiple invalid fields and assert the response is 400 with a JSON array where each element contains the expected field and message. Then send a valid request to confirm the happy path is unaffected. If you see only a generic "Bad Request" body, the payload wasn't attached or a broader handler caught the exception first.