Reading response header "Location" in Service

[Anonymous]

Hello, community.

I need to access a data source using a very stubborn API. The procedure to get the actual dataset is as follows:

1. POST credentials as a JSON body to /public/login/ to receive session cookie
2. POST to /datasets/XXX/export/csv/ to receive 202 Accepted with a download URL in the Location response header
3. GET to the download URL

I can get it working using Python or R, but those are not supported for refreshing in Service.

The only step I need which I cannot replicate in M is reading the response header "Location".

How do I solve this? I am completely stumped.

If there is no feasible way to read response headers in M?

If there is not, is there any online service that can function as a proxy and send me the full HTTP as JSON, txt or just any format, so I can parse out the Location?

Frustrated regards,

Pætur Marnason

[Anonymous · Accepted solution]

Based on this thread, it appears that you can only get the response headers within the context of a custom data connector. 

Due to that, you have to use a gateway to support refresh through the service (as described here). 

[Anonymous]

What a shame. Thank you for your time.

[v-diye-msft]

Hi @Anonymous 

Sorry I can't reproduce your issue, please kindly raise it to support team for better advice:

https://powerbi.microsoft.com/en-us/support/

[Anonymous]

I have been trying to log in to https://powerbi.microsoft.com/en-us/support/ and it just will not let me. I am logged in on Sharepoint, PBI Service as well as this site, but the support site tells me I am not logged in. If I click "Sign In" I am redirected to PBI Service. If I instead click "Sign Up Free", after typing my email it tells me I already have PBI Pro and redirects me to PBI Service.

Is there any other way to contact support? If not, can you tell them to contact me? I don't know what to do now that the official support ticket system won't let me post a ticket, even though I am a Pro user.

P.S. When you say you are unable to reproduce my issue, does that mean your Web.Content requests return other headers than just "Content-Type"?