Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ServiceComposer/ServiceComposer.AspNetCore/llms.txt

Use this file to discover all available pages before exploring further.

Endpoint filters intercept every incoming HTTP request before the composition pipeline begins. They sit at the outermost layer of a composition endpoint, running before any composition handler is invoked — making them the right tool for cross-cutting concerns such as request logging, timing measurements, rate limiting, or coarse-grained validation that should apply to all handlers on the route.
Endpoint filters for composition endpoints are available starting with v3.0.0 of ServiceComposer.AspNetCore.

​
Defining an endpoint filter

Implement the standard ASP.NET Core IEndpointFilter interface. The filter receives an EndpointFilterInvocationContext and a delegate to the next step in the pipeline: 
class SampleEndpointFilter : IEndpointFilter
{
    public async ValueTask<object> InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next)
    {
        // Do something meaningful prior to invoking the rest of the pipeline

        var response = await next(context);

        // Do something meaningful with the response

        return response;
    }
}
You can inspect or mutate the response returned by next, short-circuit the pipeline by returning early without calling next, or wrap the downstream call in a try/catch for error handling.

​
Registering endpoint filters

Endpoint filters must be registered on the IEndpointConventionBuilder returned by MapCompositionHandlers(). Chain AddEndpointFilter immediately after the MapCompositionHandlers call: 
app.MapCompositionHandlers()
    .AddEndpointFilter(new SampleEndpointFilter());
Multiple filters can be chained — they execute in registration order (outermost first): 
app.MapCompositionHandlers()
    .AddEndpointFilter(new LoggingFilter())
    .AddEndpointFilter(new TimingFilter())
    .AddEndpointFilter(new SampleEndpointFilter());

​
Accessing handler arguments from a filter

The EndpointFilterInvocationContext exposes the list of arguments that ASP.NET Core’s model binding determined were needed by the endpoint. Because ICompositionRequestsHandler implementations do not declare explicit action parameters in the MVC sense, ServiceComposer cannot automatically populate that list.
To make handler arguments visible to endpoint filters, use the declarative model binding approach when authoring your composition handlers. This tells ServiceComposer which parameters to bind and makes them available through the arguments API inside filters.

​
Endpoint filters vs composition filters

Endpoint filters

Run once for the entire composed request, before any handler executes. Best for cross-cutting concerns that apply uniformly to all handlers on the route — logging, timing, global validation, rate limiting.

Composition filters

Run immediately before a specific composition handler. Best for handler-scoped concerns — per-handler authorization checks, handler-specific input validation — even when multiple handlers share the same route.

Build docs developers (and LLMs) love

Get started for freeTalk to us