Add support for / url prefix.

[sebastienlabine]

Hi,

I'd like to handle null prefix so I can reach my app at slack-api.smartbills.io/events

right now this doesnt seem possible with the $"/{prefix}/events" patterns.

When inputing null or "", the path gets rewrited to //

[soxtoby]

Hi @sebastienlabine. The purpose of the configurable prefix is to avoid collisions with existing APIs. Given that the only place these URLs should ever be used is in your Slack app configuration, I'm not sure what the benefit of nicer URLs would be.

If you really need these custom routes though, you might be able to repurpose the SlackNet.AzureFunctions package, and set up your own controller with custom routes that just delegate to ISlackFunctionRequestHandler. It would look roughly like the Azure Function example endpoint, but be a controller instead of functions. That way you could use whatever routes you wanted.

Hope this helps.

[sebastienlabine]

Hi @soxtoby, I want to point out that the current behavior is effectively a bug. When the prefix is null or empty, $"/{prefix}/event" rewrites to //event. Technically, ASP.NET Core will still match //event, so the endpoint works, but this is invalid and unintended URL behavior. It’s confusing, non-standard, and could lead to subtle bugs or integration issues.

The main issue is that the middleware uses string concatenation instead of normalizing the prefix. A simple fix would be:

var prefix = string.IsNullOrEmpty(_configuration.RoutePrefix)
    ? string.Empty
    : "/" + _configuration.RoutePrefix.Trim('/');

This ensures:

/event when prefix is empty/null

/slack/event when prefix = "slack" (default)

Additionally, I’d like to suggest route templating as an enhancement. This would allow optional or dynamic route segments:

Versioning: /v1/event, /v2/event

Multi-tenancy: /acme/event, /globex/event

Example with TemplateMatcher:

using Microsoft.AspNetCore.Routing;
using Microsoft.AspNetCore.Routing.Template;

var routes = new Dictionary<TemplateMatcher, Func<HttpRequest, Task<SlackResult>>>
{
    [BuildMatcher($"{prefix}/event")]   = r => _requestHandler.HandleEventRequest(r),
    [BuildMatcher($"{prefix}/action")]  = r => _requestHandler.HandleActionRequest(r),
    [BuildMatcher($"{prefix}/options")] = r => _requestHandler.HandleOptionsRequest(r),
    [BuildMatcher($"{prefix}/command")] = r => _requestHandler.HandleSlashCommandRequest(r)
};

foreach (var kvp in routes)
{
    var values = new RouteValueDictionary();
    if (kvp.Key.TryMatch(context.Request.Path, values))
    {
        var result = await kvp.Value(context.Request).ConfigureAwait(false);
        await Respond(context.Response, result).ConfigureAwait(false);
        return;
    }
}

I believe this ensures valid, flexible, and readable Slack endpoint URLs while keeping existing behavior intact and enabling optional advanced routing scenarios.

[soxtoby]

Totally fair to characterize this as a bug. My default would be to throw an ArgumentException to stop people doing it, but I am open to alternatives if they make sense.

I'm not clear on what the benefit of more advanced routing would be, however. A Slack app will only send requests to a single set of endpoints, so to take advantage of multiple sets of routes, you'd need to set up multiple Slack apps, each with their own separate configuration, which is unwieldy at best, and insecure at worst if things aren't set up correctly.

If the goal is to deploy the app in multiple Slack workspaces, Slack's intended design is to have a single app, use an OAuth flow for connecting the app to another workspace, and then check the TeamId on events to distinguish between workspaces.

If you've got some other use case in mind though, please let me know, and we'll see if we can make it work.

[sebastienlabine]

I see where you’re coming from on throwing for the null behavior. I think that a valid point. In this case, we should at least support "/" as the prefix makes sense.

Right now, with even we configure /, we land on //events, which is invalid-looking. If you think about throwing an exception for this path,this would cuts off a valid and common scenario: having Slack hit a root-level route like /events.

I’d argue:
null or empty → throw (explicit misconfiguration).
"/" → normalize to /events (valid root endpoint).

That way we’re strict where it’s actually ambiguous, but still allow clean root-level URLs. Many teams (including ours) dedicate a subdomain like slack-api.smartbills.io solely for Slack traffic. Adding an extra /slack prefix in this case is redundant. Using a root-level path like /events is simpler and more intuitive.