6.3 Importing Definitions and Creating Connectors for Azure Services

A custom connector rarely needs to be built entirely from scratch. PL-400 expects familiarity with three additional entry points for creating a connector from an existing definition, plus the dedicated path for wrapping an Azure-hosted service.

Importing an Open API Definition

If the target API already publishes a Swagger 2.0 or OpenAPI 3.x document, the fastest path is Custom connectors > + New custom connector > Import an OpenAPI file (or Import an OpenAPI from URL). The wizard reads the paths, parameters, and schemas straight from the document and pre-populates the Definition tab's actions, so the developer's job shifts from authoring definitions to reviewing and refining them — adding x-ms-summary labels, tightening required fields, and configuring authentication, since OpenAPI documents do not always carry the security details a connector needs.

Importing from GitHub

Microsoft publishes the source for every certified connector — including the OpenAPI definitions Microsoft itself maintains for first-party services — in the public PowerPlatformConnectors GitHub repository. A developer can pull a connector's apiDefinition.swagger.json (and its accompanying apiProperties.json, which carries the authentication configuration) from that repository as a starting point, then modify it for a custom scenario — for example, cloning an existing connector's structure to build a similar one against an internal API, or forking a certified connector's definition to add a custom operation. This is distinct from simply installing a certified connector: pulling from GitHub gives you an editable definition you own and can extend, rather than a locked, Microsoft-maintained connector.

Importing a Postman Collection

For APIs that only have a Postman collection (exported from Postman as a v1-format collection file) rather than a formal OpenAPI document, the Import a Postman collection option converts each saved request into a connector action, inferring the verb, path, headers, and body from the collection. Because Postman collections are request-centric rather than schema-centric, the resulting connector definitions are usually rougher than an OpenAPI import — parameter descriptions, required/optional flags, and response schemas typically need manual cleanup afterward in the Definition tab or Swagger editor.

Creating a Custom Connector for an Azure Service

A dedicated fourth path exists specifically for Azure-hosted services: + New custom connector > Create from Azure service. This flow lists the Azure resources available in a connected subscription — commonly Azure Functions, Logic Apps, and API Apps — and, when the selected resource exposes Swagger/OpenAPI metadata (as an Azure Function App does when it has a Swagger extension enabled, or an API Management–fronted API does natively), auto-populates the connector's host, base URL, and even its security scheme directly from that resource.

This matters most for Azure Functions, because it is the single most common backing service for a custom connector built during PL-400-style solution work:

• If the Function App is secured with a function key, the wizard can configure an API Key authentication type that automatically supplies the key as a header or query parameter on every call.
• If the Function App is secured with Microsoft Entra ID, the wizard configures OAuth 2.0 authentication against the app registration protecting the function, so the connector inherits the same identity-based security as the function itself.

Regardless of import path, the resulting connector still passes through the same General / Security / Definition / Test wizard — importing just pre-fills those tabs rather than replacing the workflow.

Sharing and Certifying a Connector

A newly created custom connector is, by default, visible only to its owner within the environment it was created in. Two mechanisms extend that reach:

• Sharing — from the connector's Share tab, the owner can add individual users or an Entra ID security group as co-owners, letting them see, use, and edit the connector, similarly to sharing any other Power Platform component. This is the normal path for making a connector usable by the rest of a development team or by makers building apps and flows in the same environment.
• Microsoft certification — to make a connector available tenant-wide by default, or publicly to all Power Platform customers, a developer submits it through Microsoft's connector certification process, which involves opening a pull request against the public PowerPlatformConnectors GitHub repository with the connector's OpenAPI definition and metadata. Certification requires meeting Microsoft's published requirements — a valid support contact, terms of use, a compliant icon, a working authentication flow, and a security review — after which the connector is published as a standard, first-party-style entry in the global connector list rather than something each environment has to import individually.

Sharing is the everyday mechanism for team collaboration; certification is reserved for connectors intended to be reused broadly outside a single organization.