Create a custom connector from an existing API definition
The Introduction establishes the gap: the device-availability service has no built-in connector, so the equipment-provisioning team can't reach it from a flow or app. This unit closes that gap. You move from needing a connector to having one by building a custom connector directly from an API description the device-availability service already provides.
Choose how you describe the device-availability service
Every custom connector needs a machine-readable description of the API it wraps, and you rarely start from a blank page. The device-availability service, like most REST APIs, already exposes a description in one of a few common forms. Your job is to pick the import path that matches what you have.
Three practical starting points cover most real-world cases here:
- If the service publishes an OpenAPI definition as a file or a URL, you import that definition directly and the wizard reads its paths, parameters, and response shapes.
- Suppose the device-availability service is published through Azure API Management. In that case, you export it directly from the Azure portal instead of hand-supplying a file. The connector picks up the environment, display name, and any subscription-key or OAuth 2.0 settings you configure during that export. An Azure Function or other Azure-hosted API that isn't already published through API Management needs to sit behind API Management to use that path, or you import its OpenAPI definition directly instead.
- A third option exists when no definition exists yet for your own scenario but you want a working starting point: Microsoft maintains a public GitHub repository of sample connectors that you can import and adapt as a baseline.
| Import option | What it needs | Best when |
|---|---|---|
| OpenAPI definition (file or URL) | An OpenAPI 2.0 definition under 1 MB | The service already publishes a spec you trust |
| Postman collection | A Postman collection (v2) under 1 MB | The API team shares a collection instead of an OpenAPI definition |
| API Management export | An API published in Azure API Management | The API is already managed through API Management and you export it straight from the Azure portal |
| GitHub sample connector | None, you import an existing sample | You want a proven starting point to adapt |
| From scratch | Nothing | No description exists anywhere yet |
A Postman collection works the same way: if the API team shares one instead of an OpenAPI definition, you import it through the same create-connector path, as long as it's in v2 format and stays under 1 MB.
Guiding question: Think about an API you use at work that doesn't have a built-in connector today. Based on what that API's team publishes, which import option fits: an OpenAPI file, a Postman collection, an API Management export, a GitHub sample baseline, or starting from scratch?
Confirm the OpenAPI definition meets the import rules
When you choose the OpenAPI path for the device-availability service, the definition has to meet a few concrete requirements before the wizard accepts it:
- Format: The definition must be in OpenAPI 2.0 format; OpenAPI 3.0 definitions aren't supported, so if the service's description comes back as 3.0, you first convert it before you import.
- Size: The file also has to stay under 1 MB, which rarely matters for a single-service API like the device-availability service but becomes relevant if the description bundles many endpoints.
- Security definition order: If the definition includes more than one security definition, the connector only uses the topmost one. Confirm that the authentication method you need for the device-availability service sits first in the file, rather than assuming the wizard picks the right one among several.
These constraints matter because they determine how much cleanup happens before import versus after. A definition that already meets them imports cleanly, and you spend your remaining time reviewing and refining. A definition that doesn't meet them sends you back to the source before you can make progress.
Export directly from Azure API Management
Picture the device-availability service published through Azure API Management instead of handed to you as a standalone OpenAPI file. In that case, you export the connector directly from the Azure portal. In your API Management instance, go to APIs > Power Platform > Create a connector.
Then choose the API you want to export, the target environment, a display name for the connector, and any subscription-key or OAuth 2.0 settings the API requires. Once you complete the export, the connector appears alongside your other custom connectors in the maker portal, with no separate file to track down or keep in sync.
This path makes the most sense when the device-availability service is already managed through API Management. The export always reflects the current state of the API as API Management exposes it.
Suppose the device-availability service instead runs as an Azure Function or another Azure-hosted API that isn't already published through API Management. In that case, you front it with API Management to use this export path. Or you import its OpenAPI definition directly, using the file-based path described earlier in this unit.
The device-availability service in this scenario is an external, unmanaged API, so an OpenAPI file import is the more likely real-world fit. But recognizing when the API Management export applies helps you choose correctly the next time the API in question is already managed through API Management.
Where your new connector lands
Once you create the custom connector for the device-availability service, it becomes available across Power Apps, Power Automate, and Copilot Studio without any extra steps. A flow, an app, and a Copilot Studio agent can all use the same connector.
Azure Logic Apps is the exception: a connector created in Power Automate or Power Apps doesn't automatically appear in Logic Apps. If the equipment-provisioning team later needs this same connector in a logic app, you recreate it there from the same definition source.
With a working connector now standing in front of the device-availability service, the next question is how it proves who's calling. The next unit picks up exactly there, covering how you implement authentication so only the equipment-provisioning system, and not anyone else, can reach the service through this connector.