2026.3.4 - Regex POST and PATCH APIs Not Working When App at Root

Hello Sunny,

Thank you for testing 2026.3.4 so quickly, and for the clear steps to reproduce it.

We reproduced the issue in our lab on 2026.3.4, and the log you sent shows the same result on your server.

When an app is hosted at the root ("/"), regex endpoints that accept POST, PATCH or DELETE get an HTTP 405 (Method Not Allowed) with an empty body.

That empty 405 is the blank response you see.

The web routing hands the request to the app at the root before PowerShell Universal checks its regex endpoints, and that app only accepts GET.

GET requests to regex endpoints are not affected, which is why the 2026.3.4 fix looks partial.

It also explains your Invoke-PSUEndpoint result, because that cmdlet runs the endpoint inside PowerShell Universal and skips the web routing.

The GET in your log is a separate request, sent about 13 seconds before the POST.

The app at the root answered it, signed the user in with Windows authentication, and returned the app page.

The POST was not turned into a GET, and it received the 405 directly.

I am reporting this to our development team with our lab results and your log, as a follow-up to the earlier regex issue (ticket PSU-283, for internal reference only).

Moving the app away from the root still works, and we confirmed it in the lab.

If the app needs to stay at the root, there is a second workaround that we also confirmed.

Standard endpoints, without the Regex setting, accept POST, PATCH and DELETE normally when an app is at the root.

Your example URL has no regex pattern in it, so you can define it as a standard endpoint with a leading slash, and keep everything else the same:

$Var = @{ URL = '/my/api/v1/Computer/Request'; Method = @('POST','PATCH','DELETE'); Environment = 'Dedicated - API - v1'; Description = "Request API"; Authentication = $True; Role = @('Administrator', 'Requestors'); Path = "D:\Powershell Universal\Endpoints\myendpoint.ps1" }

New-PSUEndpoint @Var

In our lab, this endpoint worked next to your regex GET endpoint on the same base path.

If a write URL needs a variable part, the colon syntax also worked, for example /my/api/v1/Computer/:Id/Update.

You can find the syntax here: https://docs.devolutions.net/powershell-universal/api/endpoints/

Your GET endpoints that use regex can stay as they are.

One more point from your log: the account my\jsundberg3 received only the Reader role, while this endpoint allows Administrator and Requestors.

Please check that the account that calls the endpoint has one of those two roles.

Best regards,

Hello Patrick,

Thanks for the follow up.

Good call on the non-regex option. I can use that for the time being. I've been trying to do regex for all of them to keep things consistent, but for the time being, I can use that to get around the bug.

I mainly ended up using the regex option as I would only need to configure one endpoint that could then support multiple in-line variables with varying requirements. Example:

URL = 'my/api/v1/NamingDictionary/(?<Dictionary>[A-Za-z0-9]+)/?(?<ID>[0-9]+)?'

This supports all the variations of what this endpoint needs to support.

However, if I configured it using the non-regex way:

URL = '/my/api/v1/NamingDictionary/:Dictionary/:Id'

I couldn't then call the endpoint with/my/api/v1/NamingDictionary/Location, I would need to include a / at the end to get it to work (alternately, I'd need to create a "different" endpoint, one that only had the :Dictionary value)..

As for the roles, I am in a group that is part of the endpoint role groups. I just removed some from the configuration provided as sanitization.

Thanks,

Jacob