Set-SPOSiteScript: Issue with triggerflow URL : Invalid URL when using newer environment.api.powerplatform.com format

[SAgnihotri200895]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

None

Developer environment

None

What browser(s) / client(s) have you tested

• [ ] 💥 Internet Explorer
• [x] 💥 Microsoft Edge
• [x] 💥 Google Chrome
• [x] 💥 FireFox
• [ ] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

We are encountering an issue with the Power Automate HTTP request trigger (when a webhook is received). Specifically, the validation of the webhook URL fails when the flow is saved in one of our environments. The URL format for the webhook has changed, and the newer URL structure is being rejected by Set-SPOSiteScript.

Describe the bug / error

In our Power Automate environment, we have 4 different environments. For most of these environments (3 out of 4), the webhook URLs are generated in the following format:

https://prod-xx.japaneast.logic.azure.com:443/workflows/{id}/triggers/manual/paths/invoke?...&sig={signature}

However, for one specific environment (and all new environments), the generated URL format is as follows:

https://defaultxxxxxxxx.environment.api.powerplatform.com:443/powerautomate/automations/direct/workflows/{id}/triggers/manual/paths/invoke/?api-version=1&tenantId=...&environmentName=...

When trying to use Set-SPOSiteScript, the URL is reported as invalid. The same URL works correctly in Postman and can trigger the flow successfully. The error suggests that the URL cannot be processed because of its format or content. Problem:

The newer URL structure (environment.api.powerplatform.com) works fine in Postman, but fails during validation in Power Automate when trying to configure the script.

The validation error seems to be occurring due to the different format (OAuth-secured) of the new webhook URL.

Older environments use the prod-logic.azure.com URL format, which works fine without requiring OAuth.

Steps to reproduce

Create a flow in Power Automate in a new environment.

Add a trigger as when http request is received, Save the flow and retrieve the webhook URL.

Attempt to use the Set-SPOSiteScript with the generated webhook URL.

Encounter the validation error.

Expected behavior

The URL should be accepted by Set-SPOSiteScript, as it works fine in external systems like Postman.

[Ashlesha-MSFT]

Hello @SAgnihotri200895, Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[Ashlesha-MSFT]

@SAgnihotri200895, We were able to reproduce the issue, and we are investigating it. We have logged this as a bug, and our engineering team will look into it. Thank you!

[GC-jpellerin]

Is there any news about this error because of this morning, I have received an email from microsoft telling us that as of the 30th of november, all flow using the ".logic.azure.com:443/workflows/" will be deprecated.

The main issues reside in the fact that the acceptable parameter in the SharePoint rest api hasn't been udapted to accomadate the new type url. Many of my site script are now failing because of it. Have we a timeline of when it will be fixed?

[EddieDL]

Any update on if this will be resolved by Nov 30? @Ashlesha-MSFT

[benjagroup]

Yeah, we also have critical flows that will stop working if we cannot move the sharepoint webhook to the new URLS

[cbapexjason]

We have a similar (possibly related) issue where the new URL does not seem to allow for path parameters.

[CoktaiiL]

any updates? Meanwhile, the new URLs are also being generated on older environments for the HTTP request trigger

[StephenBoydSG]

Just adding us to the list of concerned users. Update of the URL is critical to ensuring continued use of SharePoint functions (via flows) after Nov. 30th. Thanks!

[pdl5p]

For anyone who is currently blocked by this, it looks like Azure Logic Apps are still using the logic.azure.com urls. Not sure if they are going to be updated as well, but a workaround for the current issue might be to use a logic app as a temporary proxy (or replacement) for the Power Automate Flows.

[GC-jpellerin]

I have raised a ticket with microsoft. The solution is being worked on as we speak.

[Tobajoseph-git]

I have raised a ticket with microsoft. The solution is being worked on as we speak.

Did you manage to get an update on this?

[GC-jpellerin]

I have raised a ticket with microsoft. The solution is being worked on as we speak.

Did you manage to get an update on this?

Yes, as I said, there are actively working on a patch. It should be propagated on the 15th of October (If everything goes well)

[Callum-Munro]

Issue persists on latest versions of SPO and PnP modules.

[umashankar-padhan]

Several critical flows depend on this change and will stop functioning if we don’t update the Site Script to the new URLs.any update on this?

[carlgar512]

I’m experiencing the same issue across several client workflows — these URLs are set to stop working on November 30. Is there any additional information or update on this deprecation?

[carlgar512]

I’m experiencing the same issue across several client workflows — these URLs are set to stop working on November 30. Is there any additional information or update on this deprecation?

@GC-jpellerin Do we have any news on this?

[GC-jpellerin]

It is working again through the Sharepoint API. I'm testing the trigger with different type of permission as we speak.

[SAgnihotri200895]

It is working again through the Sharepoint API. I'm testing the trigger with different type of permission as we speak.

yes, its working for me as well, need more testing though

[Callum-Munro]

Can also confirm this is now working using PnP Powershell