Register service endpoints including webhooks, Azure Service Bus, and Azure Event Hubs
The previous two units both assume the availability-service destination already exists, so the publishing code and the registered step have somewhere to send their post. This unit closes that gap. You explore how to register the service endpoint itself, as a webhook, an Azure Service Bus destination, or an Azure Event Hubs destination. That way, a target actually exists for either publishing mechanism to reach.
Register a webhook for a direct, point-to-point destination
The Plug-in Registration Tool handles service endpoint registration the same way it handles plug-ins, custom workflow activities, and virtual table data providers: through a dedicated registration option, in this case Register New WebHook. Registering a webhook asks for three pieces of information: a Name that identifies the destination, the Endpoint URL that the execution context posts to, and an Authentication option.
The destination owner, not you, decides which authentication option to configure, because the endpoint enforces whichever option it expects. Three options exist:
HttpHeaderposts one or more key/value pairs in the HTTP request header.HttpQueryStringposts key/value pairs as query string parameters.WebhookKeyposts a single query string value usingcodeas the key, the format a service like Azure Functions expects when it checks for a function key.
Whichever option the destination requires, you supply it at registration time.
Two constraints apply no matter which authentication option you choose. Registered webhooks communicate over port 80 for HTTP or port 443 for HTTPS only, and a webhook step can run either synchronously or asynchronously. When the step fires, Dataverse sends an HTTP POST request carrying the execution context as a JSON payload.
Apply that to Contoso Facilities. Registering the availability-service webhook that the previous two units both assume already exists means supplying three things. These are a name for the destination, the availability service's intake API as the Endpoint URL, and whichever authentication option that intake API requires.
One example is an HttpHeader entry carrying an API key the availability service issues. Once that registration exists, both the code-based and tool-based publishing you explore in the previous two units finally have somewhere to land.
Compare the three endpoint types at a glance
Webhooks, Azure Service Bus, and Azure Event Hubs all register through the same tool, and all result in a record in the ServiceEndpoint table. But each one expects different inputs and carries different constraints:
| Endpoint type | What you register | Key constraints |
|---|---|---|
| Webhook | Name, Endpoint URL, and an authentication option (HttpHeader, WebhookKey, or HttpQueryString) |
Port 80 or 443 only; JSON payload over HTTP POST; supports synchronous or asynchronous steps |
| Azure Service Bus | A namespace with Shared Access Signature (SAS) authorization already configured in Azure, selected during registration | Payloads over 192 KB lose certain context properties; non-queue targets need an active listener; asynchronous steps only |
| Azure Event Hubs | The same SAS-based namespace authorization as Azure Service Bus, pointed at an Event Hub instead of a queue | Suited to high-volume streams a downstream analytics or processing solution consumes |
Register an Azure Service Bus endpoint for a decoupled pipeline
A webhook destination has to be ready to receive an HTTP POST directly. Azure Service Bus works differently. You configure a Service Bus namespace in Azure first, with SAS (Shared Access Signature) authorization already in place. Only then does the Plug-in Registration Tool let you register that namespace as a service endpoint. The namespace, not Dataverse, owns the authorization model.
Once registered, the data context Dataverse posts isn't limited to the .NET binary format a plug-in would normally use. You can format it as XML or JSON instead, which matters when the system reading from the Service Bus isn't a .NET application at all. A non-.NET client hosted in Azure can read Dataverse data from the queue without needing to understand .NET serialization.
One technical limit is worth remembering before you depend on this path for large records: when the total HTTP payload exceeds 192 KB, Dataverse removes certain properties, including ParentContext, InputParameters, and the pre- and post-entity images, before posting. The message carries a MessageMaxSizeExceeded property when Dataverse trims data this way, and if the payload is still over 192 KB after trimming, Dataverse doesn't send it at all.
A destination expecting those properties on every message needs to account for the possibility that a large context arrives without them. A related detail applies if you target a messaging entity other than a queue, such as a relay: an active listener application has to already be running at that endpoint, or the post fails. Azure Service Bus steps are also asynchronous only, unlike webhook steps.
Contoso Facilities has a separate, decoupled fulfillment pipeline that doesn't need an immediate HTTP response the way the availability service does. It needs reliable delivery of request data into a queue a backend process reads on its own schedule. Registering that queue's namespace as a service endpoint, with SAS authorization configured in Azure beforehand, gives that pipeline a destination without involving the availability service's webhook at all.
Guiding question: Think about a destination in your own environment that would rather read from a durable queue than receive a direct HTTP call. What would change about how you configure authorization for that destination compared to a webhook?
Register an Azure Event Hubs endpoint for high-volume streams
Azure Event Hubs registers the same way an Azure Service Bus endpoint does, through the same tool and the same SAS-based namespace authorization. The difference is what sits on the other end. Instead of a queue or topic that a single backend process drains, you point the registration at an Event Hub built to ingest a high-volume stream of events. That's the kind of destination a downstream analytics or processing solution consumes continuously, rather than one record at a time.
For Contoso Facilities, that distinction matters if the organization later wants every request, approval, and status change flowing into a stream an analytics solution processes in near real time. The alternative is a queue a single service drains. The registration mechanics barely change; what changes is the kind of destination you point them at.
Register the step that actually starts the flow
Registering any of these three endpoint types only creates a destination. It doesn't move a single event on its own. You still need to register a step against that endpoint, the same step you explore in the previous unit: a message, a table, and a pipeline stage.
That same Register New Step dialog also includes an optional Filtering Attributes field, covered fully in the previous unit. It limits the step to updates including a given column, rather than a specific value. Only once that step exists does Dataverse start posting to the webhook, Service Bus namespace, or Event Hub you registered.
All three endpoint types register through the same tool and the same underlying ServiceEndpoint table. The remaining question isn't how to register them. It's which one fits a given destination. The next unit picks up exactly that question. It compares webhooks, Azure Service Bus, and Azure Event Hubs against each other, so you can recommend the right option for a given listening scenario.