Blog
Integrating Business Central: APIs, webhooks and Azure Functions
Almost every Business Central project ends up needing to talk to something else — a web shop, a document signing service, a data lake, a warehouse system. The good news is that BC ships with a mature integration toolbox; the risk is choosing the wrong tool and ending up with something fragile that breaks on the next update. Here is how we think about the options, and the experience behind that thinking.
Built-in REST and OData v4 APIs
Business Central exposes a large set of standard REST APIs (customers, items, sales orders, journals and more) plus OData v4 endpoints over published pages and queries. For most read and write scenarios against standard entities, you do not have to build anything — the endpoint already exists.
Why it matters: every entity you can use out of the box is an integration you do not have to develop, test or maintain through future upgrades. Always check the standard API surface before writing custom code.
Custom API pages
When the standard APIs do not cover your data — a custom table, a tailored projection, a specific field set — you expose your own API page (or API query) in AL. This gives you a clean, versioned, OData-compatible endpoint that BC treats as a first-class citizen.
Why it matters: a purpose-built API page is far more stable than scraping a UI page or abusing a generic endpoint. It survives upgrades because it is your contract, defined explicitly.
Webhooks for push notifications
Polling an API on a timer is wasteful and slow. Webhooks let BC push a notification to your endpoint the moment a record changes, so your middleware reacts in near real time instead of asking “anything new?” every few minutes.
Why it matters: push beats poll for both cost and responsiveness. Order confirmations, stock changes and status updates reach the other system promptly without hammering the API.
Azure Functions for the heavy lifting
AL is excellent inside Business Central, but it is not where you want to run complex transformations, call third-party SDKs, or orchestrate multi-step flows. That work belongs in middleware — and Azure Functions is our default home for it. BC raises an event or calls out; the Function does the mapping, retries, batching and external calls; results flow back through an API.
We have shipped exactly this pattern against SharePoint and Google Drive (document storage), AWS (cloud services), Scrive (digital signing) and bespoke Azure Functions middleware. The recurring lesson: keep BC thin and push the messy integration logic out to where it can be tested, scaled and monitored independently.
Why it matters: separating concerns keeps your BC extension small and upgrade-safe, while the heavy or volatile logic lives somewhere you can deploy and fix without touching the ERP.
Connectors: Power Platform, Shopify and friends
For common scenarios there are ready-made connectors — the Power Platform connector (Power Automate, Power Apps), the Shopify connector, and others. These are no/low-code routes that can deliver value in days rather than weeks.
Why it matters: if a supported connector covers your need, it is almost always cheaper and more durable than custom code. Reach for custom only when the connector genuinely cannot do the job.
Authentication: OAuth via Microsoft Entra
Basic authentication is gone. Modern BC integrations authenticate through Microsoft Entra (OAuth 2.0) — registered applications, scoped permissions and token-based access. Service-to-service calls use client credentials; interactive scenarios use delegated permissions.
Why it matters: Entra gives you revocable, auditable, least-privilege access with no shared passwords sitting in config files. It is more secure and far easier to govern.
Keep it upgrade-safe and resilient
Whatever you build, two principles hold. Upgrade-safe: use events and extensions, never modify standard objects, and depend on documented APIs rather than internal behaviour. Resilient: assume the network and the other system will fail — build in retries, idempotency and logging so a transient outage does not corrupt data or lose messages.
Why it matters: integrations are where most post-go-live incidents originate. Designing for failure up front is the difference between a quiet integration and a 2 a.m. phone call.
Need to connect Business Central to another system — and want it done in a way that survives the next update? Tell us your story and we will recommend the simplest, most durable approach for your case.