Unanswered

HTTP request asynchronous pattern/response issue with new flow URLs

(2) Share

Report

Posted on by LuisAguiar

I’m facing an issue when calling a Power Automate flow using the new HTTP endpoint URLs introduced by Microsoft.

The problem occurs specifically when the calling flow’s HTTP connector and the target flow response are both configured to use asynchronous responses. Instead of receiving the expected async response, the caller returns a 404 Not Found.

If I disable the asynchronous pattern either in the caller (HTTP connector) or in the target flow response, the request works and the caller receives a 202. The issue only happens when both sides are set to async.

It seems like the new URL handling isn’t correctly resolving asynchronous executions.

Has anyone else experienced this since Microsoft rolled out the new Power Automate flow URLs? Is this a known issue or regression, and is there an expected fix? I know using the HTTP Webhook connector would work, but re-implementing that across multiple flows would require significant effort in our environment.

Screenshot is only presenting the same flow being triggered by two different HTTP requests, the first with the asynchronous pattern enabled and the second with the asynchronous pattern disabled.

Categories:

Using connectors

Screenshot 2025-0...

I have the same question (8)

All responses (3)

Answers (0)

LuisAguiar 11 on at

Like (1)

Report

Just figured out that when triggering a flow through the new URL, the URL present in the "Location" header of the asynchronous response is invalid and returns 404 when sending a GET HTTP request to it, that's why the request is returning 404. Still seems to be a Microsoft side problem.

2 people found this reply helpful.

Was this reply helpful? Yes No
SurfaceWear 186 on at

Like (1)

Report

I am having the same issue.

As a short term workaround I have reverted to the old trigger URL - but this will only work until the end of September apparently!

Reforming the Location URL in the Old Format after using the NEW URL trigger URL

EDIT - I have tested this and confirm it does not work. After updating the various parameters to those returned in the header / body of a new request (primarily run ID and signature) I get an 'Unauthorized' response

I am handling the async process explicitly (i.e. getting the latest status occurs in a loop containing the HTTP GET request action using the 'Location' value from the original trigger POST HTTP request) so my next step would be to see if it's possible, when using the new Trigger URL, to reform the location url in the old format using snippets of the new 202 response. The old (working) location format appears to be:

https://[azure server].logic.azure.com/workflows/[environmentID]/runs/[workflowID]/operations/[runID]?api-version=2016-06-01?sp=%2Fruns%2F[workflowID]%2Foperations%2F[runID]%2Fread&sv=1.0&sig=[signature]

However, even if this does work in the short term - maybe this will break when the old URLs are disabled in November?

1 people found this reply helpful.

Was this reply helpful? Yes No
LuisAguiar 11 on at

Like (0)

Report

Thanks, @SurfaceWear! This old URL template helps a lot since apparently we can no longer see the old URLs inside the flows, even though it's a temporary workaround. According to this Microsoft article, the old URLs will definitely stop working on November 30.

A long-lasting solution would probably be using the "HTTP Webhook" connector, but again, in our scenario re-implementing that across multiple flows would require a significant amount of time and effort.

I've tested and found other problems with the new URLs. Custom query parameters and headers sent to them are not being parsed on the target flow. They're not even being displayed in the trigger raw outputs. That's also a big issue.

Is there a way to report these problems to Microsoft? This should be fixed asap. If we get to November 30 without any fixes, things will get ugly. I'm pretty sure this will impact about everyone using cloud flows.

Was this reply helpful? Yes No