Power Platform Custom Connectors: The Bridge Between Low-Code and Reality

A practical deep dive into Power Platform custom connectors: what they are, how to create them fast with Postman, licensing requirements, and production governance.

José Martínez Lago

José Martínez Lago

— 11 min read
Share
A bridge under construction connecting a modular low-code platform to diverse enterprise systems, representing custom connectors.

Why every enterprise eventually needs one, how to build one fast, and what it actually costs to use

For years, the default answer to almost every Power Platform integration question was reassuringly simple: pick a connector from the list.

Need SharePoint? There is a connector. Need SQL Server? There is a connector. Need to send an email, update a record, or call a standard SaaS service? Microsoft or an independent publisher has already built the connector.

Then you reach the system that does not exist in that list.

The internal API your organisation built three years ago. The legacy service that still runs the invoicing process. The third-party platform that only exposes a REST endpoint and an OpenAPI specification. The weather service, the shipping tracker, the custom authentication gateway, the on-premises database that never made it to Azure.

This is where custom connectors live. Not in the happy path, but in the gap between what the platform provides and what the business actually needs.

A custom connector is not a feature. It is the admission that no connector catalogue is ever complete, and the tool that lets you finish it yourself.

What a custom connector actually is

A custom connector is a packaged definition of how Power Platform talks to an external HTTP API. It describes the authentication method, the base URL, and one or more operations that wrap HTTP requests into callable actions.

Under the hood, it is a JSON definition that follows the OpenAPI specification. You can build it manually in the Power Platform maker portal, or you can import an existing OpenAPI document and let the platform generate the operations for you.

Once created, the connector becomes available anywhere connectors are available in the Power Platform ecosystem:

  • Power Automate as an action or trigger in cloud flows
  • Canvas Apps as a data source you can call from formulas or Power Fx
  • Azure Logic Apps as a connector action in enterprise workflows
  • Copilot Studio as a tool that agents can invoke

You can also call a custom connector from a Model-Driven App through the Web API. Technically, the API accepts the call and the connector executes. But Model-Driven Apps have their own native integration patterns: business rules, JavaScript web resources, Power Fx custom pages, and plugin pipelines. Using a custom connector from a Model-Driven App works, but it is rarely the right architectural choice. The native tools give you better error handling, proper event sequencing, and tighter integration with the Dataverse platform lifecycle.

The market reality: why custom connectors exist

Every organisation that has been running for more than five years has at least one system that Microsoft did not build a connector for.

This is not an oversight. The standard connector catalogue covers the most common enterprise services: Office 365, Azure, Salesforce, ServiceNow, SAP, and hundreds of others. But the long tail of internal APIs, niche SaaS tools, government systems, and legacy integrations is infinite. Microsoft cannot and will not build a connector for every API that exists.

Custom connectors exist because the gap between standard and custom is where real businesses operate.

Consider a manufacturing company that uses Power Platform for its service desk but still relies on an internal equipment monitoring system with a REST API. A hospital that needs to pull patient scheduling data from a system built in 2012. A logistics provider that integrates with a customs declaration service available only through a SOAP-to-REST gateway.

None of these systems will ever appear in the standard connector list. Custom connectors are the only low-code path to bring them into the Power Platform workflow.

The market need is not theoretical. It is the difference between building a solution that covers 80 percent of the process and one that covers 100 percent. Custom connectors close that final gap without requiring a full code-based integration layer.

Where custom connectors live in the Power Platform

Power Automate: the natural home

Power Automate is where custom connectors see the most use. A cloud flow can call a custom connector action just like it calls any other connector action. The operation appears in the action library, accepts the parameters you defined, and returns the response structure.

This is the most straightforward path. You define the connector, add it to a flow, and the flow handles authentication, request formatting, and response parsing through the connector definition.

Canvas Apps: data source integration

In Canvas Apps, a custom connector becomes a data source. You add it through the data panel, just like you would add SharePoint or SQL Server. Once connected, you can call its operations from Power Fx formulas, button actions, or item properties.

The same connector definition works in both Power Automate and Canvas Apps. You build it once and reuse it across the platform.

Azure Logic Apps: enterprise-grade usage

Azure Logic Apps shares the same connector runtime as Power Automate. A custom connector created in Power Platform is available in Logic Apps, and vice versa. This means you can design the connector in the Power Platform maker portal and use it in an enterprise integration workflow that runs on Azure infrastructure with stronger operational controls.

You can technically call a custom connector from a Model-Driven App through the Web API or by embedding a Canvas App component. However, Model-Driven Apps have richer native integration options:

  • Business rules for client-side logic
  • JavaScript web resources for custom client-side behaviour
  • Power Fx custom pages for app-like experiences within the model-driven shell
  • Plugin pipelines for server-side deterministic logic
  • Power Automate flows triggered by Dataverse events

These native tools are designed for the Model-Driven App runtime. A custom connector introduces an HTTP call boundary that bypasses the platform's built-in event model, error handling, and transaction management. It works, but you lose the advantages that make Model-Driven Apps powerful in the first place.

If you need external API access from a Model-Driven App, the better pattern is to call the API from a Power Automate flow triggered by a Dataverse event, or from a Power Apps Code App component that runs in a custom page.

Licensing: the premium requirement

This is the part that catches people by surprise.

Custom connectors are Premium connectors. Using a custom connector in an app or flow triggers the same licensing requirement as Dataverse, SQL Server, or any other Premium connector.

Every user who runs an app or flow that uses a custom connector needs one of these licenses:

  • Power Apps Per App plan ($5 per user per app per month)
  • Power Apps Per User plan ($20 per user per month)
  • Power Automate Per User plan ($15 per user per month)
  • Power Platform Premium (included in certain Microsoft 365 E5 plans)
  • Standalone Power Apps or Power Automate plan

This is not a per-connector licence. It is a per-user licence that covers all Premium connectors, including custom ones. If a user works with five different apps that each use custom connectors, the Per App plan means five licences. The Per User plan covers unlimited apps.

For flows that run automatically on a schedule or through an API trigger, the licence requirement applies to the flow owner or the environment's licensing context, not to individual end users who never directly interact with the flow.

Plan for this early. The connector itself is free to create, but every user who touches an app or flow that depends on it needs the Premium capacity.

Creating a custom connector: two paths

Path one: build from blank

The Power Platform maker portal provides a guided experience for building a custom connector from scratch. You define:

  1. General information -- name, description, icon, and whether it is for API management
  2. Connection parameters -- the authentication method (API key, Basic, OAuth 2.0, Certificate, or None) and any configuration values like the base URL
  3. Operations -- each operation defines an HTTP method, relative path, request headers, body schema, and response schema

The from-blank approach gives you full control. You define exactly which endpoints the connector exposes, how authentication works, and what the response structure looks like. It is also the most time-consuming path when the API has many endpoints.

Path two: import from OpenAPI (the fast lane)

If the target API already has an OpenAPI specification (formerly Swagger), you can import it directly. The Power Platform maker portal accepts an OpenAPI document URL or a file upload and generates the connector definition automatically.

Every operation in the OpenAPI specification becomes a connector operation. The authentication scheme is mapped from the OpenAPI security definitions. Request and response schemas are preserved.

This is where Postman enters the picture, and why I personally recommend it as the fastest way to get started.

Postman is an API development environment that most developers already use. It can export any collection as an OpenAPI specification, and that OpenAPI specification can be imported directly into Power Platform as a custom connector.

The workflow is straightforward:

  1. Document the API in Postman -- create requests for each endpoint you need, define the headers, authentication, and parameters
  2. Test the API in Postman -- verify that every request returns the expected response before you invest time in the connector definition
  3. Export as OpenAPI -- Postman can export a collection as an OpenAPI 2.0 or 3.0 specification
  4. Import into Power Platform -- upload the OpenAPI file in the custom connector creation screen
  5. Review and refine -- check that the generated operations look correct, fix any authentication mapping issues, and test the connector

This approach is powerful because Postman handles the hardest part: understanding the API. By the time you export to OpenAPI, you have already tested every endpoint, verified the authentication, and confirmed the response structure. The import into Power Platform becomes a mechanical step rather than a guessing game.

I have used this pattern multiple times to create connectors for internal APIs that had no documentation beyond a developer who knew how the endpoints worked. Postman becomes the documentation, the test harness, and the OpenAPI generator in one tool.

Exporting and importing custom connectors

Custom connectors are not stuck in the environment where you created them. You can move them between environments, share them with other teams, and include them in solution packages.

Solution packaging

The standard approach for moving custom connectors between Power Platform environments is through solutions. When you add a custom connector to a solution, it is packaged with its definition, operations, and connection parameter schema. The solution can then be imported into another environment.

This is the recommended path for production deployments. Solutions give you versioning, dependency tracking, and the managed/unmanaged distinction that Power Platform ALM depends on.

Direct export and import

You can also export a custom connector as a JSON file directly from the maker portal and import it into another environment. This is useful for quick sharing or backup, but it does not give you the ALM benefits of solution packaging.

OpenAPI re-export

Because custom connectors are based on OpenAPI, you can export the connector definition back to OpenAPI format. This means you can take a connector built in Power Platform and use it as the basis for a connector in another platform, or version-control the OpenAPI definition alongside your application code.

Authentication: the connector's first responsibility

Every custom connector needs an authentication strategy, and the choice affects both security and user experience.

API Key is the simplest option. The user or administrator provides a key value during connection setup, and the connector includes it in every request header. Suitable for internal APIs or services with straightforward authentication.

Basic Authentication sends a username and password with every request. Simple but less secure, especially over unencrypted channels.

OAuth 2.0 is the most robust option and the one you should prefer for production connectors. It supports delegated user authentication (the user signs in through the API provider) and application authentication (the connector uses a client ID and secret). OAuth 2.0 also handles token refresh automatically, which means the connector stays authenticated without user intervention.

Certificate-based authentication is available for scenarios that require mutual TLS. Rare but important for highly regulated environments.

No authentication is an option for public APIs, but it should be treated as a temporary measure. Even public APIs often benefit from rate-limit headers or API keys for tracking usage.

The authentication method you choose determines what users see when they connect to the connector. With OAuth 2.0, they see a sign-in dialog. With API key, they see a text field. With no authentication, the connector works immediately. Design for the user who will actually use the connector, not the one who builds it.

Governance and data loss prevention

Custom connectors introduce an external HTTP endpoint into your Power Platform environment. From a governance perspective, this matters.

Power Platform's Data Loss Prevention (DLP) policies can classify custom connectors and control which other connectors and apps they can interact with. A custom connector that calls an internal HR system should not be allowed to write to a public SharePoint site. DLP policies enforce these boundaries.

When you create a custom connector, it is automatically classified as a Custom connector category in DLP. You can then create policies that restrict which business data categories custom connectors can access.

This is not just an IT concern. It is the difference between a connector that safely bridges your platform to an internal API and one that accidentally creates a data exfiltration path.

Where custom connectors fail in production

A connector that works in the maker portal does not always work in production. Here are the failure modes I see most often:

Rate limiting. The target API has a request limit that the connector does not respect. Power Automate retries on failure, which can amplify the problem and trigger API-side blocking. Build retry logic and respect rate-limit headers.

Authentication token expiry. OAuth tokens expire. If the connector does not handle refresh tokens correctly, flows fail silently after a period of inactivity. Test the connector after a weekend or a holiday to catch this.

Response schema drift. The API changes its response format. The connector still expects the old schema. Operations fail with type mismatch errors. Version your connector operations and pin them to specific API versions when possible.

Connection scope. A connector is created in one environment and used in a flow that runs in another. The connection does not cross environment boundaries. Package the connector in a solution and deploy it to each target environment.

DLP policy conflict. The connector is blocked by a DLP policy that was created after the connector was built. The flow works in development and fails in production. Test in an environment that mirrors production DLP policies.

A practical decision framework

Not every integration needs a custom connector. Use this sequence to decide:

  1. Is there a standard connector? Check the connector library first. If Microsoft or an independent publisher has already built it, use it. Standard connectors receive updates, security patches, and platform support.
  2. Does the API have an OpenAPI specification? If yes, import it as a custom connector. This is the fastest path and gives you a complete connector definition.
  3. Can you document the API in Postman? If the API has no OpenAPI spec, build the collection in Postman, test it, export to OpenAPI, and import. This is still faster than building from blank.
  4. Do you need complex transformation logic? If the API response requires significant transformation before Power Platform can use it, consider wrapping the API in an Azure Function or Logic Apps custom connector with code, then expose the wrapper through a custom connector.
  5. Is this a Model-Driven App scenario? If the answer is yes, reconsider. Native Model-Driven patterns (plugins, business rules, Power Fx custom pages) are usually a better fit than a custom connector.

The production checklist

Before declaring a custom connector production-ready, verify:

  • Authentication works and handles token refresh
  • Every operation has been tested with real data, not just sample payloads
  • Error responses are handled gracefully (400, 401, 403, 429, 500)
  • The connector is packaged in a solution
  • DLP policies allow the connector in the target business data category
  • Users have the required Premium licensing
  • The connector has a clear owner and maintenance plan
  • API versioning is addressed (what happens when the API changes?)

The better question

The question is no longer whether Power Platform can connect to your system. It can.

The better questions are: who maintains the connector when the API changes, which identity performs the API call, what happens when the rate limit is hit, and whether the connector is packaged in a way that survives an environment refresh.

A custom connector is not a one-time configuration. It is a bridge between your platform and your reality, and bridges need maintenance.

Sources and further reading

Read more