Glossary
Webhook
By Emil Björk · Microsoft business apps consultant, Gothenburg
An HTTP POST pattern for receiving real-time notifications from Dataverse or Business Central when records change.
A webhook is an HTTP POST sent by a source system (Dataverse, Business Central, Power Automate, third-party SaaS) to a subscriber-defined URL when an event occurs. For Dynamics 365, webhooks deliver near-real-time change notifications without polling — instead of an integration repeatedly asking "has anything changed yet", the source system pushes a notification the instant something does. Dataverse webhooks fire on record events (create, update, delete, or a custom message) with a configurable payload describing what changed; Business Central webhooks fire on table changes carrying just the resource URL, leaving the subscriber to fetch the full record on receipt rather than embedding the whole record in the notification.
In practice, the appeal of a webhook is how little infrastructure it needs — no Azure resource to provision, no queue to manage, just an HTTP endpoint the source system can reach. That simplicity comes with a real cost: webhooks offer limited retry (typically a handful of immediate attempts, not a durable retry policy that survives the subscriber being down for an hour) and no durability of their own — if the subscriber's endpoint is unavailable when the webhook fires and every retry attempt exhausts, the notification is simply lost, with nothing queued waiting for the subscriber to come back. That makes webhooks well suited to low-volume, tolerant integrations where the subscriber endpoint is highly available and an occasional missed notification isn't catastrophic (refreshing a dashboard, triggering a non-critical automation).
Where confusion shows up: webhooks and Service Bus or Event Grid solve a similar-sounding problem — "notify me when something happens" — but sit at very different reliability tiers, and treating them as interchangeable is a common integration-design mistake. For anything where a missed notification has a real business consequence — a payment confirmation, an inventory adjustment that must reconcile — the standard pattern layers webhooks into something durable: webhook receiver → Service Bus queue → a durable consumer that can retry indefinitely and never silently drops a message the way a bare webhook can.
Related terms
Mentioned in these guides
- The AL test framework
- Azure Functions for Dynamics 365 integrations
- Business Central webhook subscription errors
- Credit card handling in Business Central
- Drop-ship patterns in Dynamics 365 Supply Chain Management
- Event Grid with Dataverse
- Finance and Operations and the Power Platform
- Microsoft Graph API with Business Central
- Idempotency in Dynamics 365 integrations
- Business Central webhooks vs Azure Service Bus subscribers
- Integrating Dynamics 365 with DocuSign and Adobe Sign
- Integrating Dynamics 365 with Mailchimp and SendGrid
- Integrating Dynamics 365 with Stripe and PayPal
- Integrating Dynamics 365 with Twilio for SMS and voice
- Integration patterns for Dynamics 365 CRM
- Message replay and poison queue handling for D365
- Monitoring and observability for Dynamics 365
- Polling vs push patterns for Dynamics 365 integrations
- Power Platform throttling and 429 errors
- Data integration for real-time marketing
- Run book operations after Dynamics 365 go-live
- Tenant-to-tenant migration scenarios
- Webhooks in Business Central
- Webhooks vs events in Dataverse