Custom Connectors: OpenAPI & Authentication
Bridge Power Platform to any REST API. Learn how to create custom connectors from OpenAPI definitions, configure OAuth 2.0 and API key authentication, and import definitions from existing APIs.
Connecting to the outside world
Think of a custom connector as a translator at a business meeting.
Your Power Platform apps speak βPower Fx and connectors.β External APIs speak βREST and JSON.β A custom connector sits between them, translating requests and responses so both sides understand each other.
To build a translator, you need a dictionary (the OpenAPI definition β what endpoints exist, what parameters they accept, what they return) and a security badge (authentication β OAuth, API key, or basic credentials).
The OpenAPI definition
An OpenAPI (Swagger) definition is a JSON or YAML file that describes your API:
{
"swagger": "2.0",
"info": {
"title": "LogiFlow Tracking API",
"version": "1.0",
"description": "Track shipments and get delivery estimates"
},
"host": "api.logiflow.com",
"basePath": "/v2",
"schemes": ["https"],
"paths": {
"/shipments/{id}": {
"get": {
"summary": "Get shipment details",
"operationId": "GetShipment",
"parameters": [
{
"name": "id",
"in": "path",
"required": true,
"type": "string"
}
],
"responses": {
"200": {
"description": "Shipment details",
"schema": {
"type": "object",
"properties": {
"id": { "type": "string" },
"status": { "type": "string" },
"estimatedDelivery": { "type": "string", "format": "date-time" }
}
}
}
}
}
}
}
}
Key OpenAPI elements for Power Platform
| Element | What It Becomes | Notes |
|---|---|---|
| paths | Connector actions and triggers | Each path + HTTP method = one action |
| operationId | Action name in Power Automate/Power Apps | Must be unique and descriptive |
| parameters | Input fields in the designer | in: query, in: path, in: header, in: body |
| responses.200.schema | Output fields available in the designer | Dynamic content picks these up |
| x-ms-trigger | Marks an operation as a trigger (for Power Automate) | "x-ms-trigger": "single" for webhook triggers |
Authentication types
| Auth Type | How It Works | Best For | User Experience |
|---|---|---|---|
| OAuth 2.0 | User signs in to the API provider via authorization code flow; token is managed automatically | APIs with user-specific access (Microsoft Graph, Salesforce, etc.) | User sees a sign-in popup, then connection works automatically |
| API Key | A static key sent in header or query parameter | Internal APIs, simple services, no per-user access needed | User enters the key once when creating the connection |
| Basic Auth | Username + password sent with every request | Legacy APIs, simple internal services | User enters username/password when creating connection |
| No Auth | No credentials β public API | Open/public APIs only | Connection creates instantly β no prompts |
OAuth 2.0 configuration
For OAuth, you need:
- Client ID β identifies your connector to the auth provider
- Client Secret β proves your connectorβs identity
- Authorization URL β where the user signs in
- Token URL β where the connector exchanges the auth code for a token
- Refresh URL β where the connector gets a new token when the old one expires
- Scope β what permissions the connector requests
Scenario: Marcus configures OAuth for a shipping API
Marcus builds a custom connector for NovaSoftβs Shipping Partner API. The API uses OAuth 2.0:
- Client ID: Registered in the partnerβs developer portal
- Client Secret: Stored securely (never in source control)
- Auth URL:
https://auth.shippingpartner.com/authorize - Token URL:
https://auth.shippingpartner.com/token - Scope:
shipments.read shipments.write
When a user creates a connection, they see the partnerβs sign-in page, authenticate, and grant permissions. The connector handles token refresh automatically.
Importing definitions
You do not always need to write OpenAPI definitions from scratch:
| Import Source | How | When to Use |
|---|---|---|
| OpenAPI file | Upload a .json or .yaml file | When the API provider gives you a Swagger file |
| URL | Paste the OpenAPI endpoint URL | When the API serves its own specification |
| Azure service | Select from Azure API Management or Functions | When your API is hosted in Azure |
| GitHub | Import from a public GitHub repository | When the API spec is published on GitHub |
| Postman collection | Import a .postman_collection.json | When you have a Postman collection but no OpenAPI spec |
Exam tip: Azure API Management import
If the exam describes an API hosted behind Azure API Management, the correct approach is to import from Azure APIM directly. This auto-generates the OpenAPI definition, configures authentication policies, and sets up the connector with minimal manual work. Do not write the OpenAPI file from scratch when APIM already has the definition.
Marcus needs to create a custom connector for an API that requires each user to authenticate with their own credentials. The API supports OAuth 2.0 and API key authentication. Which should Marcus configure for the connector?
π¬ Video coming soon
Next up: Custom Connectors: Azure, Policies & Code β advanced connector patterns with Azure Functions, policy templates, and code transforms.