Invoke-PSUEndpoint Oddities

@SunnyJ This is an interesting one. The problem is that you are encountering is that in 2026.3, we added an apis/execute permission to Invoke-PSUEndpoint because the service responsible for this cmdlet was exposed externally. While the endpoint itself does not enforce permissions, the cmdlet itself does. When using -Integrated, it bypasses that check and lets you call the endpoint.

Whether this is correct, is kind of up for debate because the endpoint itself is exposed as unauthenticated.

In that case, what's the best way to correct this?

Our general philosophy is most GET APIs are just open/don't require auth as the server is network protected (making it easier for other tools to integrate), but anything more elevated/secure requires auth and uses roles. Should I use -Integrated for these? Do I grant execute permission to everyone, but would that open execute to all APIs (including ones that are limited based on roles)?

@SunnyJ I think in this circumstance I would just use -Integrated to avoid having to provide permissions across all APIs and you can choose which to call directly. Is there a reason not to call the API directly with something like Invoke-RestMethod? Is it routing complexity or a performance issue? I typically consider Invoke-PSUEndpoint a bit of a backdoor into an endpoint to avoid the HTTP call but I could see in this case just calling the external API.

I generally thought that using Invoke-PSUEndpoint for things internal to PSU would be the preferred method to keep things internal, would be faster, and also negates needing to gather/parse the hostname for the call (and technically the hostname would point to a LoadBalancer in front of our prod node which would involve additional hops). There's also instances where we need to retain the end user identity (in the case of calling auth/role limited API endpoints), which I believe using Invoke-RestMethod would lose, but if you're saying Invoke-RestMethod is the preferred/recommended best practice approach, I can change things to that (assuming I'd still need to use Invoke-PSUEndpoint to call endpoints that require retaining the identity of the user accessing the app page).