A small company wants Dataverse to notify its existing order API whenever a sales order is created. The API is an always-on HTTPS endpoint they already run, volume is low, and the company has no Azure subscription and does not want to operate messaging infrastructure. Which listening option should the developer recommend?
Select an answer to reveal the explanation.
Short Explanation
If you already have a phone that's always answered, you don't need to build a call center to reach it. A webhook posts straight to the HTTPS API with zero Azure plumbing. Queues and hubs are great, but every one of them needs the Azure subscription this company doesn't have.
Full Explanation
A webhook service endpoint posts the execution context as an HTTP POST to a URL the registration specifies, with optional header or query string authentication. It requires only a reachable HTTPS receiver, which the company already operates, so it suits low-volume, near-real-time notification with no extra infrastructure. Registering the step asynchronously means a temporary failure is retried by the system job rather than blocking the save. Service Bus queues add durable buffering, but they require an Azure subscription, a namespace and a consumer that reads the queue, which conflicts with the stated constraints. Event Hubs targets high-volume streaming and also requires Azure resources; a single order API reading partitions is unnecessary complexity for low volume. A two-way contract is a Service Bus relay pattern that needs an active listener and Azure Service Bus, and per-order confirmation was never a requirement. Exam caveat: if the receiver may be offline for long periods, durable queueing becomes the better choice because webhook retries are limited. Operational check: register the webhook and an asynchronous Create step on the sales order table, create a test order, and confirm the API logs one POST containing the order's execution context.