Building Custom Connectors in Power Platform: Connect Any REST API (2026)

Why Custom Connectors Matter

Power Platform ships with over 1,000 pre-built connectors. But the API you actually need — your company's internal service, a niche SaaS tool, or that legacy system nobody wants to touch — is never one of them.

Custom connectors solve this. They let you wrap any REST API into a connector that behaves exactly like the built-in ones. Your users get the same dropdown experience in Power Apps and Power Automate, complete with IntelliSense, test buttons, and connection management. No code required on the consumer side.

As of early 2026, Microsoft has made significant improvements to the custom connector experience: the updated connector wizard supports OpenAPI 3.0 imports, the paconn CLI has reached v2 with proper CI/CD support, and AI-assisted action creation in Copilot Studio can scaffold connector definitions from natural language. This guide walks through building a custom connector from scratch — the way you would for a production integration, not a demo.

---

What You Need Before Starting

Before touching the connector wizard, make sure you have:

• A Power Platform environment with maker permissions (Developer or Sandbox environment recommended)

• The target API's documentation — you need to know the base URL, authentication scheme, and at least one endpoint

• An API key or OAuth client credentials for the target API

• Optionally, an OpenAPI (Swagger) definition file if the API provides one — this saves significant manual work

For this guide, we will build a connector for a hypothetical internal HR API that exposes employee data. The patterns apply to any REST API.

---

Step 1: Create the Connector Shell

Open make.powerapps.com, navigate to Custom connectors under the Dataverse or More menu in the left nav (the exact location depends on your environment settings).

Click + New custom connector and choose one of three starting points:

• Create from blank — start with an empty definition

• Import an OpenAPI file — upload a .json or .yaml Swagger/OpenAPI spec

• Import from GitHub — pull from Microsoft's community connector repo

If your API has an OpenAPI spec, always import it. It populates actions, parameters, and schemas automatically and saves hours of manual definition work. For this walkthrough, we start from blank to understand every moving part.

General Settings

On the General tab, configure:

Host: api.yourcompany.com
Base URL: /v2
Scheme: HTTPS
Description: Internal HR API connector for employee data

The host and base URL combine to form the root of every request. Every action you define later appends its path to this base. Get this right — changing it later means updating every action.

---

Step 2: Configure Authentication

The Security tab is where most connector projects succeed or fail. Power Platform supports four authentication types for custom connectors:

• No authentication — for public APIs (rare in practice)

• API Key — sent as a header or query parameter

• Basic authentication — username and password

• OAuth 2.0 — the standard for modern APIs

API Key Authentication

The simplest option for internal APIs. Configure the parameter name and location:

Authentication type: API Key
Parameter label: API Key
Parameter name: X-API-Key
Parameter location: Header

When users create a connection, they enter their API key once. Power Platform stores it securely and injects the header into every request automatically.

OAuth 2.0 Authentication

For APIs that use OAuth (most SaaS platforms), you need to register an application in the API provider's developer portal and configure the connector with:

Authentication type: OAuth 2.0
Identity provider: Generic OAuth 2
Client ID: <from your app registration>
Client secret: <from your app registration>
Authorization URL: https://api.yourcompany.com/oauth/authorize
Token URL: https://api.yourcompany.com/oauth/token
Refresh URL: https://api.yourcompany.com/oauth/token
Scope: employees.read employees.write

The redirect URL is generated by Power Platform after you save — copy it back into your API provider's allowed redirect URIs. This is the step people forget, and it produces a cryptic "redirect_uri mismatch" error that wastes an hour of debugging.

Gotcha: If your OAuth provider requires PKCE (Proof Key for Code Exchange), custom connectors support it as of the March 2026 update. Enable it in the advanced security settings. Previously, you had to use Azure API Management as a proxy — that workaround is no longer needed.

---

Step 3: Define Actions

Actions are the individual operations your connector exposes. Each action maps to one API endpoint. Switch to the Definition tab and click + New action.

Creating a "Get Employee" Action

Configure the action metadata:

Summary: Get employee by ID
Description: Retrieves a single employee record by their employee ID
Operation ID: GetEmployee
Visibility: important

The Operation ID is critical — it becomes the function name in Power Automate expressions and Power Fx formulas. Use PascalCase, no spaces, and make it descriptive. Changing it later breaks existing flows.

Defining the Request

Click + Import from sample and provide:

Verb: GET
URL: https://api.yourcompany.com/v2/employees/{employeeId}
Headers: Content-Type application/json

The {employeeId} path parameter is automatically detected. Edit its properties:

Name: employeeId
Type: string
Is required: Yes
Description: The unique employee identifier (e.g., EMP-10042)

Defining the Response

Add a default response by providing a sample JSON body:

{
  "id": "EMP-10042",
  "firstName": "Sarah",
  "lastName": "Chen",
  "email": "sarah.chen@yourcompany.com",
  "department": "Engineering",
  "title": "Senior Developer",
  "startDate": "2023-03-15",
  "location": {
    "office": "Seattle",
    "building": "B42",
    "floor": 3
  },
  "manager": {
    "id": "EMP-10008",
    "name": "James Rivera"
  }
}

Power Platform parses this sample and generates a schema. This schema drives the dynamic content picker — when someone uses your connector in Power Automate, they see "firstName", "department", and "location.office" as selectable fields. The richer your sample response, the better the maker experience.

Adding a "List Employees" Action with Pagination

Create a second action for listing employees with query parameters:

Summary: List employees
Operation ID: ListEmployees
Verb: GET
URL: https://api.yourcompany.com/v2/employees?department={department}&limit={limit}&offset={offset}

For APIs that return paginated results, define the pagination behavior in the connector's Code section (more on that below) or handle it in the flow with a Do Until loop that checks for a nextLink or empty results.

Tip: As of 2026, custom connectors support the x-ms-pageable extension in OpenAPI definitions. Add "x-ms-pageable": { "nextLinkName": "nextLink" } to your operation and Power Automate handles pagination automatically — no loop required.

---

Step 4: Add a Policy (Code Transforms)

The Code tab lets you write C# script that runs on every request or response. This is where you handle APIs that do not conform to what Power Platform expects.

Common use cases:

• Transforming date formats from Unix timestamps to ISO 8601

• Flattening nested response objects for easier use in Power Apps

• Adding computed fields like a full name from first + last

• Handling API quirks like non-standard error codes

Here is an example that adds a fullName field to every employee response:

public class Script : ScriptBase
{
    public override async Task<HttpResponseMessage> ExecuteAsync()
    {
        var response = await Context.SendAsync(Context.Request, CancellationToken);
        if (response.IsSuccessStatusCode)
        {
            var body = await response.Content.ReadAsStringAsync();
            var json = JObject.Parse(body);
            if (json["firstName"] != null && json["lastName"] != null)
            {
                json["fullName"] = $"{json["firstName"]} {json["lastName"]}";
            }
            response.Content = CreateJsonContent(json.ToString());
        }
        return response;
    }
}

Keep policy code minimal. Complex transformations belong in an Azure Function or API Management layer sitting in front of your API — not in connector code that is hard to debug and has a 5-second execution limit.

---

Step 5: Test the Connector

Before publishing, test every action. On the Test tab:

• Create a new connection using your credentials

• Select an action

• Fill in required parameters

• Click Test operation

The response panel shows the HTTP status, headers, and body. If something fails, check:

• 401 Unauthorized — your API key or OAuth token is wrong, or the redirect URI is not registered

• 404 Not Found — your base URL or action path is incorrect

• 500 Internal Server Error — the API itself is failing; check the request body format

---

Step 6: Use the Connector in Power Automate

Once testing passes, your connector appears in the action picker alongside built-in connectors. Here is a practical flow: notify a Teams channel when a new employee joins.

Create an automated flow with a Recurrence trigger (daily), then:

• Add your List Employees action with a filter for startDate equal to today

• Add an Apply to each over the results

• Inside the loop, add Post message in a chat or channel (Teams connector)

The dynamic content picker shows every field from your connector's response schema — firstName, department, location.office — ready to drop into the Teams message body.

For Power Apps, add the connector as a data source in your canvas app:

// In Power Fx, call the connector action directly
Set(varEmployee, HRConnector.GetEmployee("EMP-10042"));
// Use the result
Label1.Text = varEmployee.fullName;
Label2.Text = varEmployee.department;

---

Deploying with the paconn CLI

For production scenarios, never rely on the portal wizard alone. The paconn CLI (v2, released January 2026) lets you export, version-control, and deploy connectors through your CI/CD pipeline:

# Install the CLI
pip install paconn
# Login
paconn login
# Download your connector definition
paconn download -e <environment-id> -c <connector-id>
# This creates a folder with:
#   apiDefinition.swagger.json
#   apiProperties.json
#   settings.json
#   (optional) script.csx
# After making changes, deploy
paconn update -e <environment-id> -c <connector-id>

Check these files into your Git repo. Review changes in pull requests the same way you review code. This is the only reliable way to manage connectors across dev, test, and production environments.

---

Common Pitfalls and How to Avoid Them

Forgetting the OAuth redirect URI. After saving the connector, copy the generated redirect URL and register it with your API provider. The error message when this is missing is unhelpful.

Using spaces in Operation IDs. Spaces break Power Fx references. Always use PascalCase with no special characters.

Not providing response samples. Without a response schema, Power Automate cannot show dynamic content. Makers are forced to use json() and body() expressions manually — defeating the purpose of a connector.

Ignoring throttling. If your API has rate limits, document them in the action descriptions and consider adding retry policies in your flows. Custom connectors do not automatically retry on 429 responses — you handle that in flow logic or connector policy code.

Skipping environment variables for secrets. Hard-coding client secrets in the connector definition is a security risk. In 2026, use Power Platform environment variables to store secrets and reference them in your connector configuration through solution-aware deployments.

---

Wrapping Up

Custom connectors bridge the gap between Power Platform's low-code surface and the APIs that run your business. The investment in building one properly — with correct authentication, rich schemas, and CI/CD-managed definitions — pays off every time a maker drags your connector into a flow without filing a developer ticket.

Start with one well-defined API, get the authentication right, and expand from there. Once your team sees their internal systems show up in the Power Automate action picker alongside Microsoft's own connectors, the adoption conversation takes care of itself.