9.2 Registering Service Endpoints: Webhooks, Azure Service Bus & Event Hub

Microsoft Power Platform Developer Associate PL-400

Track your progress as you read

Finished sections get a check mark.

1 Introduction, Exam Overview & Developer Toolchain

0.1 PL-400 Exam Facts 0.2 Audience Profile & Required Developer Skills 0.3 The Power Platform Developer Toolchain 0.4 Extension-Point Map & AI in the Developer Workflow

2 Create a Technical Design

1.1 Analyzing Technical Architecture and Choosing Out-of-the-Box vs. Custom Solutions 1.2 Designing Authentication, Authorization, and Security Architecture 1.3 Deciding Where Business Logic Runs and Choosing the Right Table Type 1.4 Designing Reusable Power Apps Components and Custom Connectors 1.5 Designing Dataverse Code Components, Automations, and Integrations

3 Build Power Platform Solutions

2.1 Managing Power Platform Environments for Development 2.2 Dataverse Security Roles for Code Components, Least Privilege & Troubleshooting Operational Security 2.3 Solutions, Managing Dependencies & Solution Layers 2.4 Environment Variables & Connection References 2.5 Power Platform Pipelines & CI/CD with Power Platform Build Tools

4 Implement Power Apps Improvements

3.1 Complex Power Fx Formulas and Functions 3.2 Building Reusable Canvas Component Libraries 3.3 Invoking Power Automate Cloud Flows from a Canvas App 3.4 Troubleshooting Canvas and Model-Driven Apps with Monitor and Browser Debugging Tools 3.5 Optimizing Canvas and Model-Driven App Performance

5 Extend the User Experience

4.1 The Client API Object Model & JavaScript Form Scripting 4.2 Event Handler Registration & Navigation to Custom Pages via the Client API 4.3 Client Scripting Against the Dataverse Web API; Command Bar & Buttons with Power Fx and JavaScript 4.4 PCF Fundamentals: The Component Manifest & Lifecycle Events 4.5 Implementing PCF Component Interfaces; Device, Utility & Web API Features 4.6 Packaging, Deploying & Consuming a PCF Component

6 Extend the Platform: Dataverse Plug-ins & Custom APIs

5.1 Plug-in Fundamentals & the Event Execution Pipeline Stages 5.2 Execution Context & Implementing Business Logic in Plug-ins 5.3 Pre/Post Images & Organization Service Operations in Plug-ins 5.4 Registering Plug-ins with the Plug-in Registration Tool & Optimizing Plug-in Performance 5.5 Custom API Messages & Plug-ins That Implement a Custom API 5.6 Configuring Dataverse Business Events

7 Extend the Platform: Custom Connectors

6.1 Open API Definitions: Building and Extending a Custom Connector 6.2 Authentication and Policy Templates for Custom Connectors 6.3 Importing Definitions and Creating Connectors for Azure Services 6.4 Azure Functions in Custom Connectors and Data Transformation

8 Extend the Platform: Platform APIs & Azure Functions

7.1 Dataverse Web API Operations & OAuth Authentication 7.2 Organization Service Operations, Concurrency, Transactions & Bulk Operations 7.3 Service Protection API Limits & Retry Policies 7.4 Azure Functions for Long-Running, Scheduled & Event-Driven Workloads 7.5 Authenticating to Power Platform with Managed Identities

9 Extend the Platform: Power Automate Cloud Flows

8.1 Dataverse connector triggers/actions, trigger filters & retry policies 8.2 Complex expressions & flow control with error handling 8.3 Sensitive input/output parameters & Azure Key Vault 8.4 Reusable child flows & Microsoft Entra ID service principals

10 Develop Integrations

9.1 Publishing Dataverse Events: IServiceEndpointNotificationService & the Plug-in Registration Tool 9.2 Registering Service Endpoints: Webhooks, Azure Service Bus & Event Hub 9.3 Data Synchronization with Change Tracking & Alternate Keys 9.4 Upsert-Based Synchronization with the UpsertRequest Message

11 Exam Readiness & Practice

10.1 Cross-Domain "Where Do I Implement This?" Decision Framework 10.2 Exam-Day Strategy, PL-400 Item Styles & Study Plan

9.2 Registering Service Endpoints: Webhooks, Azure Service Bus & Event Hub

Key Takeaways Explain This Topic AI

Webhooks post the execution context directly to an HTTP(S) endpoint you control, registered in the Plug-in Registration Tool with a name, endpoint URL, and one of three authentication types (HttpHeader, HttpQueryString, WebhookKey).

WebhookKey authentication is the right choice for Azure Functions, since Functions expect their key under the query-string name 'code'.

Azure Service Bus Queue delivers to a single consumer without requiring an always-on listener; Topic fans the same message out to multiple independently filtered subscriptions.

One-way, Two-way, and REST are Service Bus contracts that require an actively listening consumer; Two-way and REST additionally let the listener return a value back to the calling plug-in.

Azure Event Hub is built for high-volume, one-way telemetry and analytics ingestion rather than transactional request/reply integration, and only supports SAS authentication via a connection string.

Last updated: July 2026

Once you understand how Dataverse pushes event data out through IServiceEndpointNotificationService , the next decision is where that data should go. The Plug-in Registration Tool supports three destination families for a service endpoint — webhooks, Azure Service Bus, and Azure Event Hubs — and PL-400 expects you to recommend the right one for a given integration scenario.

Webhooks: The Simplest Option

A webhook posts the execution context directly to an HTTP(S) endpoint you control, such as an Azure Function or Logic App, with no separate Azure Service Bus namespace to provision. You register it in PRT with Register New WebHook (Ctrl+W), supplying three required items:

Name — a unique label for the registration

Endpoint URL — where the execution context is posted (only port 80 for HTTP or port 443 for HTTPS is supported)

Authentication — how the endpoint verifies the request is legitimate

Three authentication types are available: HttpHeader (one or more key/value pairs sent as HTTP headers), HttpQueryString (key/value pairs appended to the URL as a query string), and WebhookKey (a single query-string value using the key name code ). WebhookKey is specifically called out as the right choice for Azure Functions , because Functions expect their authentication key under that exact query-string name. Registered webhooks are stored in the ServiceEndpoint table with a Contract value of 8 , and a step registered against a webhook works just like any plug-in step (message, table, stage, execution mode) with no extra configuration data to supply.

Azure Service Bus: Queue vs. Topic

Service Bus endpoints support several contract types:

Contract Listener required? Delivery model Notes

Queue No (messages wait until read) One consumer per message Supports destructive reads (message removed once read) and nondestructive reads; messages persist for a finite, configurable duration

One-way Yes, actively listening Fire-and-forget to a listener If no listener is active, Dataverse retries with exponentially increasing delays, then marks the job Failed

Two-way Yes Fire-and-forget, but the listener can return a string value Lets the destination pass data back into the plug-in that made the call

REST Yes Same as two-way, over a REST endpoint Used when the listener is a REST service rather than a Service Bus client

Topic No (subscribers pull independently) One message, many subscribers Each subscription can filter which messages it receives, enabling pub/sub fan-out to multiple downstream systems

A Queue is the right choice for guaranteed, point-to-point delivery to a single downstream consumer — the message waits safely even if nothing is listening at the moment it's sent. A Topic is the right choice when more than one independent system needs to react to the same Dataverse event, since each subscription can apply its own filter to the shared stream of messages. Authentication for Service Bus and Event Hub endpoints uses Shared Access Signatures (SAS) , with the claim generated by Dataverse and signed using the AppFabricIssuer certificate configured for the environment; transport is secured with TLS/SSL.

Azure Event Hubs: High-Volume Streaming

Event Hub is a distinct contract type in the same registration flow, but it's built for a different job: ingesting very high volumes of event data (Event Hubs is designed to handle millions of events per second) for streaming analytics, telemetry, or data-lake pipelines rather than transactional request/reply integration. Registering an Event Hub service endpoint only supports SAS authorization , using the connection string obtained when the event hub was created — there's no queue/topic/one-way/two-way distinction to choose because Event Hubs is inherently a one-way, high-throughput publish model.

Choosing the Right Listening Option

When a scenario asks you to recommend how an external system should listen for Dataverse events, work through this decision order:

One consumer you own, simple HTTP call, minimal setup → Webhook
One consumer, guaranteed delivery, listener doesn't need to be always-on → Service Bus Queue
Multiple independent consumers need the same event → Service Bus Topic with per-subscription filters
High-volume telemetry or analytics ingestion, throughput over acknowledgement → Event Hub
The plug-in needs a synchronous value returned before continuing → Service Bus Two-way or REST contract

Every one of these destinations is triggered the same way under the hood — through a registered step and IServiceEndpointNotificationService — so the exam-relevant skill isn't memorizing a new API per destination, it's matching the integration shape (single consumer vs. fan-out, request/reply vs. fire-and-forget, transactional vs. high-volume) to the right contract.