Skip to main content Skip to footer

Power BI REST API Connector

Since the inception of Power BI Custom Connectors, I’ve been drawn to coming up with new ones that could help my life and the lives of my customers. One of the most helpful custom connectors that I’ve created so far is the Power BI REST API Custom Connector (url).

However, in order for people to use it they had to go through a really complex set of steps where they had to register their own application, modify the custom connector until they were able to actually launch the connector in their Power BI Desktop.

A big chance occured not so long ago – a new Authentication kind has been added to the Power Query SDK called the AAD (Azure Active Directory) kind which is specific for resource that use the AAD. This is similar to how you might use the ADAL library when developing a solution in .NET. I’m no programmer / developr, so I have little to no experience working with ADAL or MSAL, but this implementation of the authentication kind goes beyond just a simple library, as it also provides an embedded first-party application created by Microsoft for anyone to use.

What does this mean? It means that it’s much easier to use the connector now as it doesn’t require anything else other than the connector file itself.

In short, with this new feature for the custom connector, all you need to do to connect to the Power BI REST API from within Power BI is to:

  1. Download the .mez file from the GitHub repo
  2. Save the file in your custom connectors folder ([Documents]\Power BI Desktop\Custom Connectors). If the folder doesn’t exist, create it and plac the file in there.
  3. In Power BI Desktop, select File > Options and settings > Options > Security. Under Data Extensions, select (Not Recommended) Allow any extension to load without validation or warning. Select OK, and then restart Power BI Desktop.
  4. Open Power BI Desktop and find the connector listed inside the Get Data window

Features found in the connector

With this connector you are able to connect to almost every single GET endpoint from the REST API. Most importantly, if you don’t find it in the long list of tables available, there’s a GETData function so you can insert any url of the Power BI REST API and query the data that you need.

One of the coolest features that I was able to introduce was a way to get the Event Activity Log data inside of Power BI through a function. Not only that, but the function itself can be used for Incremental Refresh, meaning that we could absolutely compile all of the event activity log data into a single dataset and analyze everything and anything with ease. You can read more about how to use that function from this article (url) that I wrote a few years ago.

How to schedule a refresh in the Power BI Service

Since this is a Power BI Custom Connector, it follows the same set of rules as other custom connectors. You can read Microsoft’s official documentation for the step by step on how to configure the scheduled refresh, using a gateway, of your dataset sourced from a data connector from here (url).


I’ve tested this connector for the past few years in small (dozens of workspaces and users) to big environmnts (hundreds of workspaces and users), but I’ve never attempted to use this custom connector in a huge environment with thousands of workspaces and users under the same tenant. In those cases perhaps a more granular and programmatic approach might be necessary.

The primary reason for this is that the REST API is not necessarily fast in sending the data, but the connector has been purposefully built in a way that query folding is not enabled and there’s no schema defined for most tables in an effort to make this a connector that will simply always show you all the data that we get directly from the REST API in the easist to manage way. I’ve chosen usability over performance. In theory, this will impact tenants which have ‘larger than life’ workspaces and users.

If you’re getting serious about managing your Power BI tenant, then this is a must have tool for you. Give it a try and if you find any issues please report them on the GitHub repo!



jerry deng

This is awesome and thanks for your contribution. This is the most convenient way for me as admin to extract and analyze tenant data. I have a separate workflow to store the daily event activity log and will continue using it, but your connector allows me to quickly get the other metadata (report/dataset catalog for example) to do a hollistic tenant review.

Miguel Escobar

glad it works for you!

jerry deng

Sorry please disregard my earlier question. I am able to proceed by moving the connector file to a folder location that is accessible by the gateway service account. Still having an error now with “gateway cannot be reached”, but that’s probably something specific to my scenario. Thanks again!

Antonio Palomas

Thank you very much for your contribution. This is very good and will help a lot in the administration of the Power BI Service. Congratulations on the idea and initiative to build the connector.

Ricardo Bunge

Hi Miguel — this sounds fantastic! I grabbed the .mez file, placed it in the Documents\Power BI Desktop\Custom Connectors folder, changed the security setting in PBI, but I still cannot get your connector to appear in the Get Data list. Any ideas?

Ricardo Bunge

This is actually the first one I’ve tried. I’ll have a look at that link you sent. Thanks!

Miguel Escobar

Thanks for the feedback. You can get this info using the GETData function within the connector.

You are also welcome to contribute on the GitHub repo 🙂 – that’s how most of the endpoints are appearing in there. I initially only had a few tables loaded.

Rui Caio

First of all, I would like to thank you for this. This is the easiest way to consume the API.
I’m facing only a small problem using the “DatasetDatasourcesAsAdmin”
“Error returned: OLE DB or ODBC error: [Expression.Error] The field ‘datasourceid’ of the record wasn’t found”
Could you help me with that?
Everything else is working well.
Thank you for this!

Miguel Escobar

hey! would you mind please posting your full scenario with repro steps on the GitHub so we can better track this issue?
Here’s the link to it:

Here’s also the full code for that one so you can take a look:

I believe this one was implemented by one of the contributors of the repo

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.