Custom connectors in the Power Platform

Custom connectors in the Power Platform let you call any HTTP API from Power Apps, Power Automate, and Copilot Studio as if it were a first-party connector. They're how customers and ISVs extend the platform's connector library beyond the hundreds Microsoft ships, and they're the right answer when no out-of-the-box connector exists for the API you need to call.

Anatomy of a custom connector.

• General info — name, description, icon, the API host URL.
• Security — authentication scheme (No auth, Basic, API Key, OAuth 2.0, Microsoft Entra ID).
• Definition — operations (HTTP verbs and paths), parameters, request/response schemas.
• Code — optional inline C#-like code (custom policy templates or Liquid code) to transform requests or responses on the fly.

Three ways to create one.

1. From an OpenAPI / Swagger file. Import the API's OpenAPI definition and the connector is generated automatically. The cleanest path when the source API has a maintained OpenAPI spec.
2. From a Postman collection. Import a Postman collection — Power Platform converts it into a connector definition.
3. From blank. Define operations one at a time in the custom connector designer. Useful for small APIs without a published spec.

Authentication patterns.

• No auth — public APIs only; rare in real business use.
• Basic — username + password sent in the header. Acceptable for legacy integrations, not for new ones.
• API key — a single token passed in a header or query parameter. Common.
• OAuth 2.0 — the modern path; supports any OAuth-compliant identity provider. Microsoft Entra ID, Auth0, Okta, Google, Salesforce, etc.
• Microsoft Entra ID — pre-configured OAuth 2.0 against Entra for service-to-service or delegated calls.

Throughput and limits. Custom connectors share the same Power Platform throttling: per-user per-minute call limits, per-environment limits, and per-tenant aggregate limits. APIs called from custom connectors don't bypass platform throttling.

Definition cleanliness. Spend time on the connector definition. Well-named operations, parameters with examples, response schemas that match actual returns — they're the difference between a connector users love and one that's a constant support burden. Add summaries and descriptions to every operation, parameter, and schema field; they appear in the makers' help.

Sharing. Custom connectors live inside a Power Platform environment. They can be:

• Personal to one maker (the default when created).
• Shared with users of the same environment.
• Exported in a solution and imported to other environments.
• Submitted for certification to be published in the public connector library, available to all Power Platform users globally — the right path for ISVs whose APIs deserve broad reach.

ISV-published certified connectors. ISVs whose APIs are widely used (Sana Commerce, Continia, Lasernet, others in the BC ecosystem) publish certified connectors that show up in the connector picker for every Power Platform user. The certification process is documented; it includes review for quality, security, and documentation.

Operational reality. Custom connectors are easy to start and surprisingly easy to bork — version drift between the connector definition and the source API breaks flows silently. Treat them as code: version-control the OpenAPI spec, regenerate the connector on each API version, test in dev before promoting.