Minimal API validation in .NET 10 just eliminated three NuGet dependencies from our project, and the simplicity of the new approach is worth a closer look.
The Problem with Validation Before .NET 10
Before .NET 10, validating request models in Minimal APIs meant choosing between manual validation logic, MiniValidation, or FluentValidation. Every option added packages, boilerplate, or both. Teams ended up with inconsistent error responses depending on which developer wrote the handler and which library they chose.
The .NET 10 Solution
Now it takes just two lines to enable built-in validation across your entire application:
builder.Services.AddValidation();
app.UseValidation();Decorate your models with standard DataAnnotations, and the framework handles the rest. You get automatic 400 responses with ProblemDetails, route parameter validation via attributes, and consistent error shapes across every endpoint.
Three Things Worth Knowing
- Model types must be public. Private or internal types silently skip validation. There is no error thrown, just no protection applied. This is an easy gotcha to miss during development.
- Route parameters support annotations directly. You can apply [Range], [MinLength], and other annotations directly in the handler signature, giving you validation at the route level without extra code.
- Custom business rules still work. Extend ValidationAttribute and the pipeline picks it up automatically, so you are not limited to out-of-the-box annotations.
Takeaway
The real win is not fewer lines of code. It is that every endpoint now validates the same way, with the same error format. No more inconsistent 400 responses depending on which developer wrote the handler. If your team is building with Minimal APIs in .NET 10, built-in validation should be your default starting point.
