FastEndpoints: a REPR-style alternative to Minimal APIs and MVC in ASP.NET

The problem FastEndpoints solves: route registration that outgrows one file

Minimal APIs put a handler and its route in one expression. That is fine for a dozen routes. At a hundred, Program.cs becomes a list of lambdas with no natural place to put the request shape, the response shape, the validation and the mapping. MVC goes the other way: a controller groups unrelated actions, and each action carries attributes for routing, binding and filtering. FastEndpoints takes a third position. The README describes it as "a developer friendly alternative to Minimal APIs & MVC" that "nudges you towards the REPR Design Pattern (Request-Endpoint-Response)". REPR means one class per route, so the file you open is the file you change. The topics list on the repository adds vertical-slice-architecture and minimal-api, which is the intended audience: teams building a web API in C# who want the endpoint itself to be the organising unit, not the controller and not the lambda list. It is not a general web framework and it is not a UI toolkit.

How the REPR pattern maps onto ASP.NET request handling

The mechanism is a class per endpoint. You declare an endpoint type, give it a route and an HTTP verb, and implement a handler method that receives a request object and returns a response object. Registration happens once at startup, and the framework wires the endpoint into the ASP.NET request pipeline, which is why the repository carries the aspnet and minimal-api topics alongside repr-pattern.

The data flow is the part worth understanding before adopting it. A request arrives, ASP.NET routes it to the endpoint class, the framework deserialises the incoming payload into your request DTO, runs any validator attached to that DTO, and only then calls the handler. The handler returns a response DTO, which is serialised back. Because the request and response are explicit types rather than parameters on a lambda, validation and serialisation have a fixed place to attach. That is the whole architectural bet: structure at the endpoint level, and no controller in between. The README does not spell out the pipeline internals; it points to fast-endpoints.com, so treat the site as the reference for the exact hook order rather than the repository README.

Getting the package and what the README tells you about a first endpoint

The README opens with a NuGet version badge and a NuGet downloads badge, so the package is published on NuGet under the name FastEndpoints, which is also one of the phrases people search for. The README does not print an install command, a registration call or a code sample. It links to the official website, fast-endpoints.com, and says to visit it for detailed documentation. That is the honest starting point: the GitHub page tells you what the library is and where the docs live, and nothing more.

The repository layout is the other source of structure. The solution file is FastEndpoints.slnx, sources sit under Src/, tests under Tests/, and there is a separate NativeAot.slnx at the root, which indicates the project maintains an AOT-oriented build path alongside the main one. A Benchmark/ directory and a TestHarness/ directory sit next to those. If you want to see how an endpoint is actually written before installing anything, the Tests and TestHarness directories are where the repository keeps working code, and they are more reliable than any paraphrase of the pattern.

Where the framework gets in the way

The strongest constraint is the one that makes the design work: one class per route. If your API has a handful of endpoints that share a controller base class with filters, model binders and custom action results, the REPR pattern gives you nowhere to put that shared behaviour except a base endpoint class or middleware. Teams migrating an existing MVC application should expect to rewrite the action layer, not port it.

The README also makes a performance claim that is easy to over-read. It says performance is "on par with Minimal APIs" and "does noticeably better than MVC Controllers in synthetic benchmarks", linking to fast-endpoints.com/benchmarks. Synthetic benchmarks are exactly that. The README does not give hardware, payload sizes or a reproducibility script, so the number should not be treated as a prediction for your workload. Treat the claim as a reason to run your own comparison, not as a settled result.

Finally, the README is short. It has a description, a documentation link and a sponsor list. Anything about validation, OpenAPI output, error responses or configuration lives on the website, so a reader who only opens the GitHub page will not learn how the library behaves in those areas.

FastEndpoints against Minimal APIs and MediatR-style handlers

The comparison people search for most is FastEndpoints vs Minimal API, and the difference is structural rather than behavioural. A Minimal API handler is an expression registered in Program.cs. A FastEndpoints endpoint is a type. The Minimal API approach keeps everything visible in one place and needs no convention to learn; the FastEndpoints approach trades that visibility for a fixed location for validation, mapping and serialisation. Performance is not the deciding factor, because the README puts the two on par.

Against MediatR, the difference is the direction of the abstraction. MediatR sends a request object to a handler resolved from the container, and the HTTP layer sits outside that. FastEndpoints makes the HTTP endpoint itself the handler, so there is no separate mediator step between the route and the code. That removes a layer, and it also removes the ability to reuse the same handler from a non-HTTP caller without going through the endpoint abstraction.

Against MVC controllers, the trade is grouping. Controllers group actions that share a route prefix; FastEndpoints groups nothing, which is the point, and which also means shared route prefixes and shared filters have to be expressed some other way.

Maintenance, licensing and what upgrading costs

The repository is not archived, and the last push was on 2026-09-22. Releases are frequent enough to plan around: v8.1 on 2026-03-25, v8.2 on 2026-06-24 and v8.3 on 2026-08-20. That cadence is a real cost. A library that ships a minor version every few months will keep your dependency current only if someone on the team reads the release notes, and the repository layout shows a Directory.Packages.props file, which means central package management is available to you when pinning versions across projects.

The licence is MIT, and the LICENSE.md file sits at the repository root. MIT is permissive: it allows commercial use and modification with the copyright notice retained. That is a statement about the licence text, not legal advice, and if you redistribute the library inside a product you should read LICENSE.md yourself rather than take a summary.

The upgrade surface is the endpoint base class and the registration calls. Because endpoints are ordinary classes, a breaking change in the base class signature touches every endpoint file you own. That is the flip side of having no shared controller: there is also no shared place to absorb a change.

Editorial conclusion

Adopt FastEndpoints if you already run ASP.NET 8 or newer and your route table has grown past the point where lambda registration stays readable, since the unit of change becomes one file with its request, response and validator. Do not adopt it if you want a single Program.cs or you rely on MVC filters and model binders, because the REPR shape discards both. Before committing, verify that your NuGet feed resolves the FastEndpoints package for your target framework and that your OpenAPI document still describes every route after the switch, because the README points to fast-endpoints.com for that detail rather than stating it.

Frequently asked questions

Official sources

1. FastEndpoints/FastEndpoints on GitHub
2. License: MIT
3. Project website
4. README
5. Releases