Custom connectors

What it does

A custom connector is a wrapper you build around a REST API so that Power Automate, Power Apps, Logic Apps and Copilot Studio can call it with named triggers and actions instead of raw HTTP. You describe the API once — from an OpenAPI definition, a Postman collection, or by hand in the portal — and makers then get a first-class connector in the designer.

Key facts

Three build paths: OpenAPI definition, Postman collection, or start blank in the custom connector portal. Power Automate and Power Apps support all three; Logic Apps uses the first two.
Supported auth: generic OAuth 2.0, service-specific OAuth 2.0 (Microsoft Entra ID, Dropbox, GitHub, Salesforce), basic auth, and API key. Microsoft recommends Entra ID.
OAuth 2.0 custom connectors use a per-connector redirect URI. Connectors created before this change had to be migrated off the shared global redirect URI, and unmigrated ones stop accepting new connections.
Connectors built in Power Automate are available in Power Apps and Copilot Studio and vice versa. Logic Apps connectors don't cross over — you rebuild from the same OpenAPI definition.
Certification through Microsoft's submission process is what makes a connector available to all Power Platform users globally, not just your tenant. Sharing inside the organisation is a separate, much simpler operation.
In an environment linked to a Virtual Network, connectors created before the link have to be resaved, and OAuth and token requests don't transit the VNet — only API endpoint calls do.

When to use / skip

Build a custom connector when the same API gets called from more than one flow or app, when you want the auth handled once rather than per-flow, or when you need the operations to show up in DLP policies as a distinct thing an admin can classify. For a single call to a single endpoint in a single flow, the HTTP action is less work and less to maintain. The tipping point is usually reuse or governance, not technical capability.

Configuration decisions

Which auth type the connector uses, and whether the identity is a service principal or the calling user.
Whether the connector lives inside a solution so it moves through environments with the rest of the ALM, versus being created loose in an environment.
Whether you certify publicly or just share within the organisation — certification is a long process with Microsoft review and validation attached.
How the connector is versioned when the underlying API changes, and who owns that.
Whether connection references are used so the connector's connections aren't hardwired to the deployer's account.

Gotchas

Changing a field in the API means republishing the connector and then removing and re-adding the connection in every app and flow that used it. Existing connections don't pick up the new definition on their own.
Custom connectors created outside a solution have to be re-pointed by hand in every environment. Put them in a solution from day one — retrofitting is painful.
Custom connector operations are premium-class, so the licence conversation from standard vs premium applies here too.
OpenAPI definitions generated by API tooling often need hand-editing before Power Automate accepts them; response schemas in particular tend to come through too loose to give useful dynamic content.

Consultant notes

Position custom connectors as an integration asset with an owner and a lifecycle, not a one-off build task. Somebody has to maintain it when the API changes.
Push for a solution-aware connector plus connection references in the first sprint. It's cheap then and expensive later.
Warn the client that certification is Microsoft's timeline, not yours — never put it on a critical path.

Worth revisiting if the client's API changes shape, or after the next release wave touches connector authoring