HTTP Redirect when calling changeFiles JSON with Power Automate

[PhilLarkin1]

In Power Automate, when requesting via POST to the changeFiles endpoint, I am redirected to an azure CDN.

When requesting from Postman the JSON content is returned. I've attempted to mimic Postman requests under many different content type and header/body configurations. To no avail, I am always redirected. Ultimately I am able to get at the edits json in Power Automate, but it via 302 which feels dirty. I want this to work properly. Any tips? @Anonymous User @hgaignard 

Example changeFiles URL: https://services1.arcgis.com/[tenant]/ArcGIS/rest/services/[name]/FeatureServer/changefiles/[quid].json

Example Postman code

POST /[org]/ArcGIS/rest/services/[name]/FeatureServer/changefiles/04605422c530[....]debc94.json HTTP/1.1
Host: services1.arcgis.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 205

token=qko6HoysMcv5-[....]FU&f=json

Example Power Automate result

[PhilLarkin1]

Power Automate classifies a 302 response as a failed state. There hacky ways to overcome this, but the flow will still 'fail'. How unfortunate....

[Anonymous User · Accepted solution]

Hi @PhilLarkin1 - It's a good question - I reproduced the issue in Power Automate; the redirect is also seen when downloading the change file from the Rest endpoint:

Integromat, Postman, and the Rest UI are able to handle the redirect to Azure storage to get the file without returning any errors but it seems like Power Automate is not able to. Did you end up implementing something like this as a workaround? 

https://powerusers.microsoft.com/t5/Building-Flows/How-to-Handle-HTTP-302-Redirects-in-MS-Flow/td-p/...

I did hear the engineers working on webhooks/feature layers have been focusing on Power Automate this release cycle - so there may be some updates within a month or so. I've reached out to them as well to get their take on it. 

I hope this helps,

-Peter 

[PhilLarkin1]

Hi @Anonymous User 

Thanks for your reply. 

Yes, I had previously implemented that workaround. It is not ideal. It also requires that parallel branches end with a Terminate action showing Success or Fail depending on the logic of the branch. This makes error catching tricky.

Also multiplying the complexity of flows dealing in ESRI's REST API, is the fact that there are a multitude of schemas that are returned from arcgis server requests. They may or may not include a status code. The status code might not reflect the truth. For example the 504 Timeout code is wrapped in the JSON of a 200 response. Every response must be dealt with differently. Would be nice if every REST function adhered to a standard. 

Thanks for participating in the forum. 

[Anonymous User]

Thank you for the feedback on this @PhilLarkin1 .