Business Central webhooks vs Azure Service Bus subscribers

External systems need to know when a Business Central record changes: a shipment posted, a customer created, an item's price updated. Polling the API every few minutes works and is how most integrations start. When polling stops being good enough, Business Central offers webhook subscriptions on its API, and Azure offers Service Bus for anything you are willing to publish yourself from AL. They solve the same problem at very different levels of effort and reliability, and the choice depends on what happens if a notification is lost.

How Business Central webhooks work

You create a subscription against an API page (standard or custom) with a callback URL. When a record exposed by that API is inserted, modified, or deleted, Business Central sends a notification to the URL. The notification tells you the resource and the change type. It does not carry the record's data; the subscriber then calls the API to fetch what changed. Subscriptions expire after a fixed period and must be renewed. The receiving endpoint must complete a validation handshake when the subscription is created.

That model is deliberately lightweight. Business Central batches notifications, may deliver them with a delay of up to several minutes depending on load, and will drop a subscription that repeatedly fails to respond. There is no replay of missed notifications and no guarantee of ordering. Our webhooks in Business Central guide covers the setup mechanics.

How the Service Bus pattern works

Nothing in Business Central publishes to Service Bus out of the box. You write an AL extension that subscribes to the relevant events (OnAfterPostSalesDoc, OnAfterInsertEvent on the table you care about, or a custom business event), builds a message, and sends it to a Service Bus queue or topic over HTTPS from AL, with the Service Bus credentials held in isolated storage or Azure Key Vault. Downstream systems consume from the queue at their own pace, with Service Bus providing durable storage, retries, dead-lettering, and ordering within a session.

The message can carry the full payload so consumers do not need to call back into Business Central. The trade-off is that you now own an extension, its error handling, and the question of what happens when the Service Bus call fails inside a posting routine. The usual answer is an outbox table in Business Central written in the same transaction as the business event, with a job queue entry draining it to Service Bus, so that a Service Bus outage never blocks a posting. See the outbox pattern with Service Bus for the general shape.

Business events: the third option

Business Central also ships business events, a curated set of application-level events (sales order released, invoice posted) that publish to Dataverse and from there to Power Automate. This is the low-code middle ground: no AL, no polling, richer semantics than a table-level webhook. It routes through Dataverse, which means Power Automate is the natural consumer and the event set is Microsoft's, extensible in AL if you need your own. For notifying Power Platform, business events are usually better than either webhooks or Service Bus. For notifying a non-Microsoft system, they are one more hop.

Deciding

Use webhooks when the subscriber is a single system, a delay of minutes is fine, a missed notification is recoverable by the next one or by a periodic reconciliation, and you do not want to write AL. Syncing a product catalogue to an e-commerce platform is a good fit; the catalogue will be reconciled nightly anyway.

Use Service Bus when several systems need the same events, when losing an event has a business cost (a posted invoice that never reaches the payment platform), when ordering matters, or when consumers cannot be reached synchronously and need to catch up later. Order-to-cash and finance postings belong here.

Use business events when the consumer is Power Automate or something else in the Power Platform and the event you need is in the standard set.

The lost-notification test

Ask what happens if one notification never arrives. If the answer is "the next scheduled reconciliation picks it up", webhooks are fine and cheap. If the answer is "a customer does not get their goods", you need durable messaging and an outbox, and the extra AL is the cost of that guarantee. Most integrations that start on webhooks and later migrate to Service Bus do so after a lost notification caused a visible problem.

Operational differences

Webhook subscriptions expire; something must renew them, and forgotten renewals are the most common failure. The receiving endpoint must be reachable from the internet and respond quickly, which usually means an Azure Function or Logic App in front of anything on-premises. Service Bus needs no inbound endpoint, works from anywhere, and has queue depth and dead-letter metrics you can alarm on; see message replay and poison queue handling.

Both patterns need reconciliation. Even with Service Bus, a periodic comparison between Business Central and the downstream system catches the cases where a message was consumed but the consumer's write failed.

Cost

Webhooks are free apart from the compute that receives them. Service Bus is inexpensive at typical ERP volumes, and the real cost is the AL extension and the discipline to maintain it. Business events sit in between and consume Power Platform request capacity.

Stability verdict

Webhooks are stable but limited by design, and they have not changed much in years. The Service Bus pattern is stable because you built it, and it will be as reliable as your outbox and your consumers. Business events are the newest and the one most likely to grow in scope. Our broader AL events and integration patterns guide covers the AL side in more depth.