πŸ”’ Guided

Pre-launch preview. Authorised access only.

Incorrect code

Guided by A Guide to Cloud
Explore AB-900 AI-901
Guided PL-400 Domain 5
Domain 5 β€” Module 4 of 9 44%
18 of 26 overall

PL-400 Study Guide

Domain 1: Create a Technical Design

  • Solution Architecture: What Goes Where Free
  • Security by Design: Auth, Roles & DLP Free
  • Designing UX Components: Canvas, PCF & Client Scripts Free
  • Designing Platform Extensions: Connectors, Plug-ins & APIs Free
  • Integration & Automation Blueprints Free

Domain 2: Build Power Platform Solutions

  • Environment Setup & Security Troubleshooting
  • Solutions & Layers: ALM Foundations
  • CI/CD Pipelines for Power Platform

Domain 3: Implement Power Apps Improvements

  • Advanced Power Fx & Canvas Components
  • Troubleshoot & Optimise Apps

Domain 4: Extend the User Experience

  • Client Scripting: Form Events & the Client API
  • Commands, Buttons & Custom Page Navigation
  • PCF Components: Build & Lifecycle
  • PCF Components: Package, Deploy & Advanced Features

Domain 5: Extend the Platform

  • The Plug-in Pipeline: How Dataverse Processes Events Free
  • Writing Plug-ins: Business Logic, Service & Registration
  • Custom APIs & Business Events
  • Custom Connectors: OpenAPI & Authentication
  • Custom Connectors: Azure, Policies & Code
  • Dataverse APIs: Web API & Organisation Service
  • Azure Functions for Power Platform
  • Cloud Flows: Dataverse Triggers & Expressions
  • Cloud Flows: Security, Errors & Child Flows

Domain 6: Develop Integrations

  • Publishing Dataverse Events
  • Service Endpoints: Webhooks, Service Bus & Event Hub
  • Data Sync: Change Tracking, Alternate Keys & Upsert

PL-400 Study Guide

Domain 1: Create a Technical Design

  • Solution Architecture: What Goes Where Free
  • Security by Design: Auth, Roles & DLP Free
  • Designing UX Components: Canvas, PCF & Client Scripts Free
  • Designing Platform Extensions: Connectors, Plug-ins & APIs Free
  • Integration & Automation Blueprints Free

Domain 2: Build Power Platform Solutions

  • Environment Setup & Security Troubleshooting
  • Solutions & Layers: ALM Foundations
  • CI/CD Pipelines for Power Platform

Domain 3: Implement Power Apps Improvements

  • Advanced Power Fx & Canvas Components
  • Troubleshoot & Optimise Apps

Domain 4: Extend the User Experience

  • Client Scripting: Form Events & the Client API
  • Commands, Buttons & Custom Page Navigation
  • PCF Components: Build & Lifecycle
  • PCF Components: Package, Deploy & Advanced Features

Domain 5: Extend the Platform

  • The Plug-in Pipeline: How Dataverse Processes Events Free
  • Writing Plug-ins: Business Logic, Service & Registration
  • Custom APIs & Business Events
  • Custom Connectors: OpenAPI & Authentication
  • Custom Connectors: Azure, Policies & Code
  • Dataverse APIs: Web API & Organisation Service
  • Azure Functions for Power Platform
  • Cloud Flows: Dataverse Triggers & Expressions
  • Cloud Flows: Security, Errors & Child Flows

Domain 6: Develop Integrations

  • Publishing Dataverse Events
  • Service Endpoints: Webhooks, Service Bus & Event Hub
  • Data Sync: Change Tracking, Alternate Keys & Upsert
Domain 5: Extend the Platform Premium ⏱ ~13 min read

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

β˜• Simple explanation

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).

Custom connectors wrap REST APIs into the Power Platform connector framework. They are defined by an OpenAPI (Swagger) specification that describes available endpoints, parameters, request/response schemas, and authentication methods. Once created, the connector appears in the Power Apps and Power Automate designer like any built-in connector.

The connector definition can be created manually, imported from an OpenAPI file, auto-generated from an Azure service (API Management, Azure Functions), or imported from a GitHub repository. Authentication options include OAuth 2.0 (authorization code grant β€” user-delegated), API key (header or query parameter), and basic authentication.

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

ElementWhat It BecomesNotes
pathsConnector actions and triggersEach path + HTTP method = one action
operationIdAction name in Power Automate/Power AppsMust be unique and descriptive
parametersInput fields in the designerin: query, in: path, in: header, in: body
responses.200.schemaOutput fields available in the designerDynamic content picks these up
x-ms-triggerMarks an operation as a trigger (for Power Automate)"x-ms-trigger": "single" for webhook triggers

Authentication types

OAuth 2.0 is the most common exam topic β€” know the flow
Auth TypeHow It WorksBest ForUser Experience
OAuth 2.0User signs in to the API provider via authorization code flow; token is managed automaticallyAPIs with user-specific access (Microsoft Graph, Salesforce, etc.)User sees a sign-in popup, then connection works automatically
API KeyA static key sent in header or query parameterInternal APIs, simple services, no per-user access neededUser enters the key once when creating the connection
Basic AuthUsername + password sent with every requestLegacy APIs, simple internal servicesUser enters username/password when creating connection
No AuthNo credentials β€” public APIOpen/public APIs onlyConnection creates instantly β€” no prompts

OAuth 2.0 configuration

For OAuth, you need:

  1. Client ID β€” identifies your connector to the auth provider
  2. Client Secret β€” proves your connector’s identity
  3. Authorization URL β€” where the user signs in
  4. Token URL β€” where the connector exchanges the auth code for a token
  5. Refresh URL β€” where the connector gets a new token when the old one expires
  6. 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 SourceHowWhen to Use
OpenAPI fileUpload a .json or .yaml fileWhen the API provider gives you a Swagger file
URLPaste the OpenAPI endpoint URLWhen the API serves its own specification
Azure serviceSelect from Azure API Management or FunctionsWhen your API is hosted in Azure
GitHubImport from a public GitHub repositoryWhen the API spec is published on GitHub
Postman collectionImport a .postman_collection.jsonWhen 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.

Question

What is an OpenAPI (Swagger) definition?

Click or press Enter to reveal answer

Answer

A JSON or YAML file that describes a REST API: available endpoints, HTTP methods, parameters, request/response schemas, and authentication. Power Platform custom connectors use OpenAPI 2.0 (Swagger) format to understand the API structure.

Click to flip back

Question

What is the operationId in an OpenAPI definition?

Click or press Enter to reveal answer

Answer

A unique identifier for each API operation. In Power Platform, the operationId becomes the action name in Power Automate and Power Apps. It should be descriptive (e.g., 'GetShipmentById', 'CreateOrder') because makers see it when building flows and apps.

Click to flip back

Question

How does OAuth 2.0 authentication work for custom connectors?

Click or press Enter to reveal answer

Answer

When a user creates a connection: (1) they are redirected to the auth provider's sign-in page, (2) they authenticate and grant permissions, (3) the provider returns an authorization code, (4) the connector exchanges it for an access token, (5) the token is stored and refreshed automatically. The user only signs in once.

Click to flip back

Knowledge Check

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.

← Previous

Custom APIs & Business Events

Next β†’

Custom Connectors: Azure, Policies & Code

Guided

I learn, I simplify, I share.

A Guide to Cloud YouTube Feedback

© 2026 Sutheesh. All rights reserved.

Guided is an independent study resource and is not affiliated with, endorsed by, or officially connected to Microsoft. Microsoft, Azure, and related trademarks are property of Microsoft Corporation. Always verify information against Microsoft Learn.