PowerPlatformConnectors is where the source of every Power Platform connector lives

Three folders, three different relationships to Microsoft

The repository is described as the open source home for the Power Platform's connectors, and it is organised by who owns the service behind them. The `custom-connectors` folder holds fully functional samples that can be deployed to the platform for your own use, and the documentation points anyone who wants to publish to the other two folders instead. The `certified-connectors` folder holds connectors built by partners who own the end service, and those are deployed and available out of the box in the platform, with the certification programme requiring that new certified connectors be open sourced for community contributions. The `independent-publisher-connectors` folder is the interesting middle case, connectors submitted by publishers, individual developers and companies, who do not own the service behind the connector. Those are deployed out of the box too, but as premium connectors, and the folder is managed by the Independent Publisher Connector Community, which brings together the publishers themselves and the project coordinators. Anyone can submit a new connector there, add functionality to one, or resolve issues with one, which is a much more open door than the certified path.

The branch rule is what keeps the platform honest

The branch structure is the part worth internalising before you make a change. The `master` branch is maintained by the Microsoft Connector Certification Team, and its purpose is to ensure that the version of the connector in the repository is identical to the version deployed in the Power Platform. The `dev` branch is maintained by the connector owner together with the certification team, and it is where community development happens before certification and deployment. So the model is a two step release, work lands on dev, certification happens, and the same content is promoted to master, where it can no longer change without breaking the promise that the source matches what runs. The default branch of the repository is `dev`, which is the correct place to open a pull request. The same rule applies to the independent publisher folder, with the master branch held by the certification team and the dev branch held by the connector maintainers and the team together, and the Independent Publisher Connector Manifesto in the wiki sets out how that group works.

A connector is three files, and two of them have schemas

The contribution guide is specific about what a connector is, and the answer is three files. The first is the API definition, the swagger, which describes the API for the connector using the OpenAPI specification, and there is a JSON schema for it at `schemas/apiDefinition.swagger.schema.json` that the file is validated against. The second is the API properties file, which holds the things that are not part of the API definition itself, such as the brand colour and the authentication information, with its own schema at `schemas/paconn-apiProperties.schema.json`. The third is the README. The properties file is where the connector's identity and its connection parameters live, and a typical connection parameter looks like this:

      "api_key": {
        "type": "securestring",
        "uiDefinition": {
          "constraints": {
            "clearText": false,
            "required": "true",
            "tabIndex": 2
          },
          "description": "The KEY for this API",
          "displayName": "KEY",
          "tooltip": "Provide your KEY"
        }
      }

The `securestring` type and the `clearText` constraint are what stop the platform from rendering a secret in plain text, and the `uiDefinition` block is what the connector's form is actually built from.

Four properties that decide how your connector behaves

The properties file has a small number of meaningful fields, and the documentation explains each. `properties` is simply the container. `connectionParameters` defines the connection parameter for the service, and it is the field that decides what a user is asked for when they add the connector. `capabilities` describes the capabilities of the connector, with the examples being cloud only or on-prem gateway, which tells the platform whether the connector can run against a local gateway. `iconBrandColor` is the icon brand colour in HTML hex code, and the rule here is specific: independent publisher connectors must set it to `#da3b01`, while a custom connector example in the documentation uses `#007EE6`. The last field is `policyTemplateInstances`, an optional list of policy templates and values applied inside the connector, and the example in the guide applies a `setqueryparameter` template named `MyPolicy` that overrides a query parameter. So a connector is not only an API description, it also carries the identity, the connection form, the deployment topology and the gateway policies.

The README is a deployment manual, not a summary

The third required file gets the most attention in the guide, and the reason is stated plainly. The README is meant to be a standalone guide for deploying and using your connector by other users and developers, and it should include a description of the connector, any prerequisites a developer or contributor needs, instructions on how to use the connector and the API, how to get credentials, the supported operations, and the known issues and limitations. A named example is pointed at, the Azure Key Vault custom connector, and there are templates for both the certified connector readme and the independent publisher one. The OAuth case has its own requirement, and it is the one that catches people out. If your independent publisher connector needs OAuth, the README must explain in detail how to create the OAuth application, because the Microsoft Certification Team uses those instructions to create the app for you. Write that section carefully and completely, or the certification step stalls on a question only you can answer.

The fork workflow, and the upstream remote people forget

Contributing starts in the way you would expect, with a fork button, a sync, and a clone. The documentation then gives the commands, and the middle one is the one to pay attention to:

git clone https://github.com/YOUR-USERNAME/PowerPlatformConnectors.git
git remote -v
git remote add upstream https://github.com/microsoft/PowerPlatformConnectors.git

So the clone comes from your own fork, the `git remote -v` step is there to check what you actually got, and the third command is what adds the canonical repository as an upstream so you can fetch and rebase against it. Contributors usually need a CLA, a Contributor License Agreement, which the documentation explains as declaring that you have the right to grant the rights to use your contribution, with the details at the Microsoft CLA site. The repository also carries a `SECURITY.md`, a `NOTICE` file, a `metadata.json`, a `schemas/` directory, a `templates/` directory, a `scripts/` directory, a `tools/` directory and a `.pipelines/` directory for the automation, and the licence is MIT.

What the repository is for, and who it is not for

It is worth being clear about the shape of the thing, because the name suggests a library and it is not one. There is no package to install, no API to call, and no code that runs in your application. What is here is source and metadata for connectors, the schemas that validate them, and the process for getting one published. The consequence is that the value of the repository to an engineer is mostly as a reference, since production connectors with a consistent structure are a good way to learn how the Power Platform expects an API to be described, authenticated and documented, and the custom connector samples are runnable examples of a working integration. The consequence for a publisher is that the path depends on who you are. If you own the service, the certified route is available and the requirement is that the source is open. If you do not, the independent publisher route is available, with a premium connector as the commercial model and a review that the documentation treats as a collaboration rather than a gate. And the repository publishes no GitHub releases, with the last push on 2026-10-15, so what you depend on is the state of the default branch, which is `dev`.

Editorial conclusion

PowerPlatformConnectors suits a company that owns an API and wants a connector for the Power Platform, since a custom connector gets it into the platform without a certification cycle, and it suits a developer who wants to see how production connectors are structured and documented. It is a poor fit if you want to publish a connector for a service you do not own and expect a free ride, since the independent publisher path runs as a premium connector and carries a review, and it is a poor fit if you are not prepared to work in the certification team's release discipline. Before you contribute, check three things: which of the three folders your connector belongs in, since the requirements differ, that your fork and your upstream remote are set up correctly, because the fork workflow in the documentation is easy to get subtly wrong, and the terms you are agreeing to, since most contributions require a Contributor License Agreement.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/PowerPlatformConnectors on GitHub
4. Project website
5. README