Microsoft-Certified Power BI REST Connector Now Available!

Thanks for sharing the update ​@Everton Colling . This is an awesome update to the existing version and will help us solve a lot of limitations.

Thanks for getting a new version out there and documenting it. Excited to test this out!

​@Everton Colling  Are incremental refreshes supported with the new REST connector?

Hi ​@Anders Brakestad! Yes, incremental refresh can be set up using the new REST connector, as long as the resource/endpoint you are trying to fetch supports server side filtering on a time range.

The way Microsoft enabled this feature is a bit complex, but you should be able to accomplish it by following instructions here: https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview. There’s even an example fetching data from a REST endpoint using Web.Contents that would be very similar to what happens with the REST connector which uses this function under the hood.

Be mindful that, different than OData, for REST endpoints, if you pass a filter that results in no data, an empty Table without any columns/properties would be returned. For Power BI service to join tables using incremental refresh, a given Power Query table needs to always return the same schema (list of columns). That means you need to do maintain a list of columns/properties you are interested to fetch from a given endpoint an make sure the Power Query code would always return these columns. I’ll try to work on adding a tutorial with some examples to our public documentation in the coming weeks to help users setup this functionality using the new connector and REST endpoints.

Great, thanks for the quick reply!

The tutorial about incremental refresh has now been published here: https://docs.cognite.com/cdf/dashboards/references/rest/powerbi_rest_incremental_refresh

Great! I’ll test it out and report progress here.

Thanks for sharing the tutorial update regarding the Power BI connector. It would be great to have a session on the pros and cons of using the OData and REST options. Example: 
 

Let’s say you want to connect Power BI tomanages customer work orders.
 

Using OData:
 

✅ Pros:

• Easy to integrate.

• Good for tabular, structured data.

• Built-in support in Power BI.

❌ Cons:

• Limited in handling complex nested data.

• Less flexibility for custom logic or advanced queries.
   

Using Rest API:
 

✅ Pros:

• More flexible.

• Can access richer or more complex data structures.

• Supports more modern APIs (JSON-based).

❌ Cons:

• Requires more effort to configure.

• Complex pagination and transformation logic.

• Harder to manage in Power BI without coding skills.

Hi Andre,

Thanks for your comment! Your breakdown of OData vs REST is on the right track and highlights some of the key trade-offs one needs to consider when choosing which protocol to pick.

It's important to understand that the CDF REST API came first and is the primary way to fetch data from CDF with full flexibility and performance. OData and GraphQL were added later as services built on top of the REST API to serve as convenience layers, without the goal of having complete feature parity with the full REST API.

OData was our first choice and the only protocol supported on our first Power BI connector as it has a series of benefits for the user. Recently, when we started looking into adding support for Cognite authentication in our Power BI connector, we worked together with Microsoft to explore what options were available to overcome the limits imposed by the OData only approach. We then added direct REST API access while keeping the OData option. This means our customers get both the ease of OData and the full power of our REST APIs.

Now that I explored a bit the history and some background for better context, let me expand on the comparison by breaking down the options available in the new Power BI connector:

OData APIs support

• Great for quick data exploration in Power BI (no-code)
• Useful when connecting to legacy resources or simple data models
• Great for straightforward use cases with limited data volumes
• Best when prioritizing user-friendliness with minimal setup

However, it is slower than direct REST APIs and less suitable for complex queries and transformations in Power Query. As mentioned above, it also doesn't expose data from all CDF resources/endpoints.

GraphQL support

• Specifically designed for querying CDF Data Models
• Excellent when you need precise control over fetching specific fields and relationships
• Makes it easy to construct and test queries visually in the CDF interface

The limitations are that it's primarily for CDF Data Models (not all resource types), and is less flexible for accessing diverse or non-modeled data compared to REST APIs. In most cases can be a middle ground between OData and REST (GET/POST), as users can create powerful queries without writing Power Query code.

CDF REST APIs support

• Provides the highest performance, especially for large datasets
• Gives access to any Generally Available CDF service or resource type
• Offers maximum flexibility for data retrieval and complex integration
• Ideal when implementing sophisticated data transformations in Power Query

The main drawbacks are that it might require some programming knowledge for complex queries and has a steeper learning curve for users unfamiliar with APIs. All features and filters exposed by CDF REST APIs are available for the creation of semantic models.

As a summary, OData is still available as a user friendly option for simple reports, but if you are a serious Power BI developer, you should consider learning Power Query as it opens up a wide range of possibilities for building high performant and rich data reports. 

We are working on an updated series of courses on the Cognite Academy for Power BI and I’ll make sure we include a section on the pros and cons of the different interfaces to pick from when creating a new semantic model in Power BI.

Great stuff,  ​@Everton Colling !
Thanks a lot for the detailed explanation and guidance.