Custom connector

What is a custom connector?

A custom connector is one you build yourself when no ready-made connector exists for a source or destination you need to reach. The prebuilt catalogues are large, Power Platform alone ships more than a thousand connectors, but they never cover every niche ERP or internal system. When yours is missing, you wrap the target's API in a connector of your own.

Custom connectors in Power Automate and Logic Apps

This is the version most people meet first. In Power Automate, Power Apps and Logic Apps, a custom connector is a wrapper around a REST or SOAP API. You describe the API with an OpenAPI definition (the format has to be OpenAPI 2.0, formerly Swagger) and pick an authentication method: OAuth 2.0, an API key, or basic authentication.

The platform then turns each endpoint into a named action. A raw POST /v2/orders call becomes a "Create order" step anyone can drop into a flow, no code required. Say a local ERP has a REST API but no public connector. You import its OpenAPI file, set OAuth 2.0, rename the endpoints to business actions, and every flow can call it like a built-in connector. It fills the low-code gap an iPaaS tool leaves for services it does not cover.

What a connector has to handle

Behind a friendly action sits real plumbing. A connector that reads data reliably has to handle several things at once:

• Authentication. Sign in and refresh tokens with no human present, usually through OAuth 2.0 or an API key.

• Pagination. Walk results page by page instead of assuming one response holds everything.

• Rate limits and retries. Stay under the API's rate limit, and apply a retry policy with backoff when a call fails or is throttled.

• Incremental extraction. Track a cursor or timestamp so each run is an incremental load of new and changed rows, not a full re-pull.

• Schema and type mapping. Map the source's JSON fields to typed columns, and decide what happens when the source adds or renames one.

Ingestion tools hand you a framework for this. The Fivetran Connector SDK builds a source connector in Python that manages state and schema, and a Power Query connector does the same in the M language, packaged as a .mez extension.

Build versus buy

Building the connector is the cheap part. The bill arrives later, when the upstream API changes. A renamed field, a new required parameter, or a change in pagination or authentication can break every flow or pipeline that depends on the connector. Microsoft's own guidance is blunt: change a field and you must republish the connector, then remove and re-add the connection in each app that used it. A custom connector is a small piece of software you own and watch.

So the choice comes down to one question: who should own that maintenance? Buy, or wait for, a ready-made connector and the vendor absorbs every API change. Build your own and the job is yours, in return for reaching a source nobody else supports. Build when the source is genuinely unsupported, internal, or niche, or when you want to shape raw endpoints into a few clean actions. Lean toward buying when a maintained connector already exists, even an imperfect one, because a connector you never patch is usually worth more than a perfect one you do.