Microsoft DataConnectors holds the legacy path into Power Query extensions

The repository's own README points you somewhere else

The first thing in the documentation is an update notice, and it changes how the whole repository should be read.

It says that a new version of the Power Query SDK has been released and is in Public Preview, available from the Visual Studio Code Marketplace, and that all future investments in regards to the Power Query SDK will go towards that new SDK. Contributors are pointed to a new discussions section in the new SDK's own GitHub repository, which is microsoft/vscode-powerquery-sdk, and given a quickstart guide for it.

So this repository is where the old path lives. The top-level entries confirm it: there is a PowerQuerySdk.vsix file, which is the packaged Visual Studio extension, and the single GitHub release is v1.0.0.25, named for the Power Query SDK for Visual Studio 2019 and marked as legacy in its release title.

The default branch is master, the last push was on 2026-06-08, and the repository is MIT licensed. The primary language is listed as PowerShell, which is a clue to the shape of the project rather than a claim about where the interesting code lives, since a connector's behaviour is written in M.

A connector is an M extension with a data source kind

The mechanism behind Data Connectors is the M language. Extensions allow you to define new functions for the M language, and can be used to enable connectivity to new data sources. The same M language is used by the Power Query user experience in Power BI Desktop and in Excel 2016.

The documentation is careful about scope. While the guide focuses on defining new connectors, much of the same process applies to defining general purpose M functions.

The defining piece of a connector is the data source kind. The Hello World sample in the documentation declares a section named HelloWorld with a DataSource.Kind attribute and a Publish attribute, and the sample's structure is what a connector author copies to start. The documentation points to the Power Query Connector Developer Reference for the details on authentication handling.

Extensions vary in complexity, and the documentation names both ends of the range. At the simple end are wrappers that essentially just provide branding over existing data source functions. At the complex end are rich connectors that support Direct Query, where Power BI queries the source live rather than importing it.

That distinction is the first design decision any connector author has to make, and it determines whether the connector needs to implement navigation tables, parameterised queries or a full query language.

The quickstart is a Visual Studio project that drops an extension file in a folder

The build and install path in this repository is a Visual Studio based flow. The documented steps are to install the Power Query SDK from the Visual Studio Marketplace, create a new Data Connector project, define the connector logic, build the project to produce an extension file, copy the extension file into the `[Documents]\Power BI Desktop\Custom Connectors` directory, and open Power BI Desktop.

So the deliverable is an extension file placed in a known directory on the user's machine. Power BI Desktop loads the extensions automatically on restart.

For development, there is one extra step. To load extensions during development you have to lower the security level for extensions so unsigned and uncertified connectors can load. The instructions are to go to File, then Options and settings, then Options, then the Security tab, and under Data Extensions to select the option that allows any extension to load without warning or validation, then restart Power BI Desktop.

That setting is the reason the flow works at all on a developer machine, and it is also the reason you cannot ship an uncertified connector to end users without going through certification. The documentation points to the Connector Certification page for the process and requirements.

The samples directory is the most useful thing in the tree

The samples are where a connector author actually starts, and the list covers the connector patterns that come up in practice.

The packaged SDK, the sample set and the test framework sit at the top level of the repository:

PowerQuerySdk.vsix
samples/
testframework/

Inside the sample set there are fourteen connectors covering the common cases. HelloWorld is the minimal case. HelloWorldWithDocs is the same thing with documentation files, which is what a real published connector needs. NavigationTable shows the table navigation pattern, and NativeQuery shows how to push a query to the source. OData and OpenApiSample cover the two API styles that most SaaS sources expose. ODBC demonstrates talking to a database driver, and DuckDbFlightSQL shows a SQL engine running inside the connector process.

Authentication gets two samples of its own. OAuthPKCE covers the PKCE flow for a public client without a secret, and TripPin is the reference service that appears throughout the documentation, including as the worked example for gateway support. Github is a real-world connector against a public API.

Then there is UnitTesting, which sits alongside a testframework/ directory at the repository root, and a sample named DataWorldSwagger for an OpenAPI-described service.

The listing is a catalogue of connector shapes. A developer picking a starting point can pick the sample that matches their source type rather than assembling one from scratch.

Gateway support is what separates a real connector from a local one

A connector that works in Power BI Desktop is not automatically usable in a company deployment. The Power BI On-Premises Gateway supports loading custom connectors, and the documentation links both the technical documentation and the TripPin sample as an example of how to add gateway support to a connector.

The distinction in practice is where the code runs. A desktop connector runs on the analyst's machine and can reach whatever that machine can reach. A gateway connector runs on a machine inside the customer's network, which is where the sensitive data usually lives, and which is the only place that can reach an on-premises SQL Server or a file share.

For a connector meant for real corporate use, this is the part that cannot be skipped, and the fact that the repository ships a dedicated gateway sample with a public reference service to test against is the practical reason to keep this tree around.

The repository also has a SECURITY.md and a CODE_OF_CONDUCT.md, and the presence of an editors/ directory alongside docs/ suggests that the documentation and editor support are maintained as part of the same tree.

Where the M language reference material lives

Because a connector is a piece of M code, the reference material matters as much as the samples, and the documentation links it directly.

The M Language Specification and the M Library Functions reference are both linked, alongside the Data Connector Technical Reference for data access patterns, the Connector Developer Reference for authentication, the Connector Certification page, the gateway support technical documentation, and the Data Connector Samples directory.

For context on the wider ecosystem, the Power BI Developer Center is linked, and the recordings section points to a Creating a Custom Data Connector session from the Microsoft Data Insights Summit in 2017, alongside a deep dive into the M language video.

The scale of the project should be judged correctly. This is a samples-and-reference repository with one packaged SDK artefact, one legacy release from 2024, and a documentation set that has been overtaken by a successor project. Its value to a connector author today is as a well-organised catalogue of M patterns and as a marker of the certification requirements you will eventually have to meet.

Editorial conclusion

Adopt this repository as a reference for writing Power Query extensions in M, particularly the sample connectors, since it collects HelloWorld, OAuthPKCE, OData, ODBC, TripPin and a unit testing framework in one tree. Skip it as a starting point for new tooling, because the Visual Studio 2019 SDK it packages is marked legacy and all future investment goes to the Visual Studio Code SDK in the vscode-powerquery-sdk repository. Verify first that the SDK you intend to use matches, that the connector extension you build is meant for Direct Query or only import, and that the sample you start from includes the authentication handling your data source actually needs.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/DataConnectors on GitHub
4. README
5. Releases