Hmm I asked Claude. The ManagementApiBase by itself does not do that much and you can actually pretty easy create a minimal api controller yourself. However, adding to swagger seems to be the harder part and you need to fight the framework a little for it.
The ManagementApiControllerBase doesn’t really do much on its own. It’s an abstract controller whose main job is to stack a set of attributes that together make an endpoint “part of the Management API”. The helper methods on it are just conveniences.
The attributes it applies are:
[ApiController] for standard API behaviour and model validation[Authorize(Policy = BackOfficeAccess)] which requires an authenticated backoffice user (this is the lock-down part)[Authorize(Policy = UmbracoFeatureEnabled)] plus the IUmbracoFeature marker for feature gating[MapToApi("management")] which groups the endpoint into the management OpenAPI document (this is what puts it in Swagger)[JsonOptionsName(BackOffice)] for the backoffice JSON options- a few filters (
AppendEventMessages, DisableBrowserCache, MaintenanceModeActionFilter)
Note it does not set the route. The /umbraco/management/api/v{version}/ prefix comes from a separate route convention, not from the base class. So being a Management API endpoint is really four separate concerns bundled together: routing, auth, OpenAPI grouping, and JSON options.
On whether the minimal API approach works:
Auth is fine. You can apply the same policy to a minimal endpoint:
app.MapGroup("/umbraco/management/api/v1/mything")
.RequireAuthorization(AuthorizationPolicies.BackOfficeAccess);
Swagger is the catch. Umbraco decides what goes into a document in ConfigureUmbracoOpenApiOptionsBase.ShouldInclude. The [MapToApi] check only applies to ControllerActionDescriptor, so it never matches minimal APIs. The only other way in is the fallback that checks ApiVersionMetadata.Name == ApiName. So to get a minimal endpoint into the core management document you’d have to attach Asp.Versioning metadata whose version set is named management. That’s possible but hacky, and you’d be injecting into the document that generates the backoffice TypeScript client (which ships pre-generated as an embedded OpenApi.json).
The cleaner route, and what the official extension template does, is to not piggyback on the core document at all. Create your own named API with its own OpenAPI document:
[ApiController]
[BackOfficeRoute("umbracoextension/api/v{version:apiVersion}")]
[Authorize(Policy = AuthorizationPolicies.SectionAccessContent)]
[MapToApi(Constants.ApiName)]
public class MyApiControllerBase : ControllerBase { }
That gives you backoffice auth plus your own Swagger doc without touching core.
So short version: you can secure minimal APIs with the same policy easily, but forcing them into the core management Swagger doc is fighting the framework. If you just want them locked down and documented, give them their own API name and document rather than reproducing ManagementApiControllerBase against the management one.
(