Reports API returns 401 (unauthorized)

[initsoftware]

We are using the API through JavaScript and accessing "https://api.powerbi.com/v1.0/myorg/reports" which returns a 401 (Unauthorized).

However for example using "https://api.powerbi.com/v1.0/myorg/groups" works and returns the groups of the powerbi user so our implementation should be correct. The app has all required permissions set in azure portal including "Read and Write all Reports". 

Any idea what could be the issue here?

[Eric_Zhang]

---

@initsoftware wrote:

We are using the API through JavaScript and accessing "https://api.powerbi.com/v1.0/myorg/reports" which returns a 401 (Unauthorized).

However for example using "https://api.powerbi.com/v1.0/myorg/groups" works and returns the groups of the powerbi user so our implementation should be correct. The app has all required permissions set in azure portal including "Read and Write all Reports". 

Any idea what could be the issue here?

---

@initsoftware

Could you register a new APP following this tutorial App registration and permissions and retry? I'm not reproducing your issue when having the app registered as the link.

[initsoftware]

Hi @Eric_Zhang,

looks like it is working now although I haven't changed anything in my implementation. Did anything change on your end? Now reports and dashboards sucesfully return values.

What would be the be the best way to access the data behind a tile from a dashboard? I am able to get the metadata through myorg/dashboards/dashboardID/tiles/tileID but what I'm really looking for is the data underneath.

Thanks for your help and hopefully you can point me in the right direction.

[initsoftware]

For any interested, I found my answer here: https://community.powerbi.com/t5/Service/How-to-identify-which-data-set-is-used-by-a-report-and-how-...

Unfortunatly it also seems that the API can only access datasets which have been created with the API (see here https://community.powerbi.com/t5/Developer/Power-BI-REST-API-Table-and-Row-query-return-with-404-err...).

This seems like a huge oversight and we will probably look for some other solution for our case.