Business Central APIs and Integrations: A Practitioner Guide

Ask a room full of people who have lived through a Business Central implementation where the project nearly came off the rails, and very few of them will point at the finance module, the posting logic or the chart of accounts. They will point at the integrations. The nightly sync that silently stopped. The e-commerce orders that duplicated during a retry storm. The bank feed that mapped a customer payment to the wrong account for three weeks before anyone noticed. Integration is the connective tissue of a modern ERP, and it is also the part that is least visible in the sales cycle and least understood at go-live. After more than two decades building integrations across ERP, EAM and enterprise systems, I have come to treat the integration layer not as plumbing bolted on at the end, but as a first-class part of the architecture that deserves the most careful design of anything in the project. This guide is how I think about connecting Business Central to the world around it.

The message up front: Business Central ships with a genuinely good, standards-based integration surface. The REST API, OData web services, OAuth security and the surrounding Microsoft stack give you everything you need to build clean, durable connections. The technology is rarely the reason integrations fail. They fail on design decisions: the wrong pattern, weak master data, no idempotency, no monitoring, and no plan for the day the API version changes. Get those right and integration stops being the scary part of the project.

1. Why integration is where ERP projects succeed or fail

An ERP is only as valuable as the data flowing into and out of it. Business Central can run finance, supply chain, sales and operations beautifully, but almost no organisation runs its entire business inside one system. The website takes the orders. The CRM owns the customer relationship. The bank holds the cash. The warehouse management system moves the stock. A CMMS or field-service platform manages the assets. Payroll, tax, logistics and a dozen niche tools each own a slice. The ERP is the financial and operational spine, but it is surrounded by a nervous system of connected applications, and the integrations are what make the whole organism behave as one.

That is precisely why integration carries disproportionate project risk. The functional modules are configured and tested inside a single, well-understood system. Integrations cross boundaries between systems owned by different teams, on different release cycles, with different data models and different definitions of the same word. "Customer" means one thing in the CRM and a subtly different thing in Business Central. An order is confirmed at one moment in e-commerce and posted at another moment in the ERP. Every integration is a negotiated agreement about meaning, timing and ownership across a boundary, and every one of those agreements is a place where the project can quietly go wrong.

The value is equally concentrated there. A clean integration between Business Central and the sales channel means orders flow without rekeying, stock levels are trustworthy, and finance closes on real numbers instead of reconciled guesses. A broken one means duplicate orders, stale inventory, manual correction, and a slow erosion of trust in the numbers that is far more damaging than any single error. The integration layer is where an ERP either becomes the single source of truth the business relies on, or becomes one more system people work around. For a wider view of how Business Central fits within the broader Microsoft platform, the Business Central and the Microsoft ecosystem pillar sets the context this guide builds on.

2. How Business Central exposes itself: the REST API, OData and standard versus custom APIs

Before you can integrate anything, you need to understand the doors Business Central opens for you. There are several, and choosing the right one is the first architectural decision that matters.

The REST API is the modern, preferred front door. Business Central publishes a RESTful web API, versioned and based on a set of well-defined resources such as customers, vendors, items, sales orders and journals. You interact with it over HTTPS using standard verbs, GET to read, POST to create, PATCH to update, DELETE to remove, and you receive and send JSON. Because it follows REST conventions and is versioned, it is stable, predictable and friendly to almost any integration tool or language on the other side. For most new integrations, this is where you start.

OData web services are the older but still widely used mechanism. Business Central lets you expose pages and queries as OData endpoints, which gives you a queryable, filterable interface over almost any data the page surfaces. OData is powerful precisely because it can reach data the standard API does not model, and it supports rich query options such as filtering, selecting specific fields and expanding related records. The trade-off is that OData endpoints exposed from pages are more tightly coupled to the internal application than the curated REST resources, so they can be more sensitive to change. Think of OData as the flexible, reach-anything option and the REST API as the curated, stable option.

Within the REST world there is a further distinction that trips people up: standard APIs versus custom APIs. The standard API set is Microsoft's out-of-the-box collection of resources covering the common entities most integrations need. It is maintained by Microsoft, versioned, and consistent across environments, which makes it the safest choice when the entity you need is already covered. But no standard set covers every scenario, especially once you add extensions and industry-specific data. That is where custom APIs come in: using AL development you define your own API pages and queries, exposing exactly the fields and entities your integration needs, under your own API publisher, group and version. A well-designed custom API gives you a clean, stable contract shaped around your integration rather than around whatever a standard page happens to surface.

The practitioner's rule I follow: use the standard API when it covers the entity, build a purpose-designed custom API when it does not, and treat page-based OData as the flexible fallback for reaching data neither of the first two exposes cleanly. Reaching for OData on an internal page just because it is quick is how you end up with an integration that breaks the next time someone modifies that page. For the AL side of building those custom endpoints, see the Business Central extensions and AL development pillar.

3. Authentication and security: OAuth, service-to-service and least privilege

Every integration is a door into your financial system, and how you secure that door matters more than almost any other decision in the design. Business Central's web APIs authenticate through Microsoft Entra (the identity platform formerly known as Azure Active Directory) using OAuth 2.0. Older basic-authentication approaches that relied on a username and web-service access key have been progressively retired in the cloud, and for good reason: a static key that grants access to your ERP is exactly the kind of long-lived credential that leaks and lingers.

For system-to-system integrations, the pattern you want is service-to-service authentication, where the integrating application authenticates as itself rather than impersonating a human user. You register the application in Entra, grant it the specific permissions it needs in Business Central, and it obtains an OAuth access token using its own credentials (the client-credentials flow). The token is short-lived, scoped, and can be revoked centrally without touching the integration code. No human account is tied to the machine process, which means the integration does not break when someone leaves the company or changes their password, and there is no shared human login quietly holding the keys to finance.

The principle that should govern all of this is least privilege. An integration that only needs to read items and post sales orders should have permission to do exactly that and nothing more. It should not run as an administrator because that was easier during testing. Business Central's permission sets let you scope what an integration account can see and do, and you should scope them tightly, then test that the integration genuinely cannot reach beyond its remit. The blast radius of a compromised or buggy integration is defined by the permissions you gave it, so give it the minimum.

The honest caution: the most common security shortcut I see is an integration built during a rushed go-live using an over-privileged account and a credential pasted into a config file "just to get it working," with every intention of tightening it later. Later never comes. That account outlives the project, accumulates access, and becomes the single most dangerous artifact in the estate. Set up service-to-service auth and least-privilege scoping from the first day of build, not as a hardening task afterwards, because the temporary shortcut has a way of becoming permanent infrastructure.

4. Integration patterns: point-to-point, middleware and iPaaS, event-driven, batch versus real-time

Once you can reach and authenticate against Business Central, the next question is the shape of the integration itself. The pattern you choose determines how the connection behaves under load, how it fails, and how much it will cost you to change later. A handful of patterns cover almost everything.

• Point-to-point: the integrating system talks directly to Business Central, and Business Central talks directly back. Simple, fast to build, and perfectly reasonable for one or two connections. The problem is combinatorial: connect five systems point-to-point and you can end up with a tangle of direct links, each with its own auth, its own error handling and its own quirks. Point-to-point is the right answer for a small, stable number of integrations and the wrong answer for a growing estate.
• Middleware and iPaaS: instead of every system talking to every other, connections route through an integration layer, an integration platform as a service such as the Azure integration services, or a dedicated middleware tool. The middleware owns transformation, routing, retries and monitoring in one place. This adds a component to run and understand, but it turns a tangle of bespoke links into a managed hub, and it is where any estate with more than a few integrations eventually needs to go.
• Event-driven: rather than one system polling another asking "has anything changed?", the source system emits an event when something happens and interested systems react. This is more efficient, more timely and more scalable than constant polling, and it is the direction modern integration architecture leans. Business Central supports this through webhooks and change notifications, covered further below.
• Batch versus real-time: cutting across all of the above is the question of timing. Batch integration moves data in scheduled bulk runs, for example a nightly export of the day's transactions. Real-time (or near-real-time) integration moves each record as it happens. Batch is simpler, cheaper, easier to reconcile and perfectly adequate for data that does not need to be instant, such as end-of-day financial postings. Real-time is essential where the business genuinely needs immediacy, such as showing live stock availability to a customer on a website. The mistake is defaulting everything to real-time because it sounds better; real-time is more complex, more failure-prone and more expensive, and much of what people ask for in real time is perfectly fine as an hourly or nightly batch.

The insight that saves the most pain: choose the simplest pattern that meets the actual business requirement, not the most sophisticated one available. A nightly batch that reconciles cleanly and fails loudly beats a real-time event stream that nobody monitors and nobody fully understands. Sophistication is a cost, not a virtue. You buy it only when the requirement genuinely demands it, and you should be able to say out loud why this particular integration needs to be event-driven or real-time rather than a scheduled batch.

5. Azure Logic Apps, Power Automate and the Microsoft integration stack

One of the quiet advantages of Business Central is that it lives inside a mature integration ecosystem you do not have to assemble from scratch. Microsoft provides a layered set of tools that connect to Business Central through ready-made connectors, so much of the plumbing is already built.

Power Automate is the accessible, low-code layer. It lets you build automated flows triggered by events, such as a new record in Business Central or an incoming email, and carry out actions across hundreds of connected services. Its Business Central connector exposes common triggers and actions without a line of code, which makes it ideal for departmental automations and lighter integrations: route an approval, notify a channel when a large order posts, copy a record between apps. It is the tool a capable business user can wield, and for a large class of "when this happens, do that" needs it is exactly right. The dedicated Business Central and Power Automate pillar goes deeper on where it shines and where it does not.

Azure Logic Apps is the professional-grade sibling. It shares the connector ecosystem with Power Automate but sits in the Azure platform with the operational maturity that serious integration needs: enterprise-scale monitoring, deployment through infrastructure-as-code, versioning, and integration with the wider Azure messaging services. When an integration needs to be robust, observable and owned by an IT team rather than a department, Logic Apps is usually the better home. The rough division I use: Power Automate for user-driven, departmental automation, Logic Apps for system-to-system integration that has to run reliably and be operated professionally.

Around both sit the heavier Azure integration services, message queues and service buses for reliable asynchronous delivery, event grids for event routing, and API management for governing and securing the APIs themselves. You will not need all of these on a small estate, but knowing they exist keeps you from reinventing reliability and governance by hand. And because AI is increasingly part of this stack, the same connector and API foundation is what lets tools reach into Business Central intelligently, a theme explored in the Azure OpenAI and custom AI agents for Business Central pillar.

6. Webhooks and near-real-time integration

Polling is the crude way to keep two systems in sync: every few minutes, one system asks the other "has anything changed since I last checked?" It works, but it is wasteful when nothing has changed and slow when something has. Webhooks invert the model. Instead of the consumer repeatedly asking, the source notifies the consumer the moment something relevant happens. Business Central supports this through subscriptions to change notifications on API resources: you register a subscription against a resource, and when a record in that resource is created, updated or deleted, Business Central sends a notification to the endpoint you nominated.

The important subtlety, and one that catches people out, is that the notification typically tells you that something changed and which resource, but it is not itself the full payload of the changed data. The consuming system uses the notification as a trigger to go and fetch the current state of the affected record through the API. This "notify then fetch" pattern is deliberate: it keeps the notification lightweight, and it means the consumer always reads the authoritative current state rather than trusting a payload that might be stale by the time it is processed. When you build against webhooks, design for that two-step rhythm rather than expecting the notification to carry everything.

Webhook subscriptions also expire and must be renewed, and notifications can occasionally arrive more than once or out of order, which is normal for distributed messaging and not a defect. That reality feeds directly into the next section: any near-real-time integration must be built to tolerate duplicate and out-of-sequence messages, because at scale it will receive them. Used well, webhooks give you responsive, efficient, near-real-time integration without the cost and waste of constant polling, and they are the right foundation when the business genuinely needs timeliness.

7. Common integration scenarios: CRM, e-commerce, bank, CMMS, warehouse and third-party apps

The patterns above become concrete in the handful of integrations almost every Business Central estate ends up building. Each has its own character.

• CRM: keeping customers, contacts, quotes and orders consistent between a CRM platform and Business Central is one of the most common needs. The hard part is not the mechanics, it is agreeing who owns what. Does the CRM or the ERP own the customer master? Where is the source of truth for pricing? A clear ownership model per field, decided before any code is written, is what makes CRM integration durable rather than a perpetual reconciliation headache.
• E-commerce: the online store creates orders and needs live stock and pricing; Business Central owns fulfilment, invoicing and inventory. This is the classic case where part of the flow wants near-real-time (stock availability shown to a shopper) and part is fine as batch (settling the day's orders into finance). Splitting the integration by timing requirement, rather than forcing all of it into one cadence, is the design move that keeps it both responsive and reliable.
• Bank integration: importing statements and reconciling payments, and increasingly initiating payments outward, connects Business Central to banking systems. This is the integration where correctness matters most and errors are least forgivable, because a mis-mapped payment is real money in the wrong place. Bank integration rewards conservative design: strong validation, clear reconciliation, and a human checkpoint on anything that does not match cleanly.
• CMMS and asset management: where Business Central handles procurement and finance and a separate CMMS manages maintenance and assets, the integration links purchase orders, spare-parts consumption, work-order costs and asset values across the boundary. This is territory I know well, and the recurring lesson is that the two systems model an asset differently, so the mapping between them is the whole game. The Business Central and CMMS integration pillar treats this scenario in depth.
• Warehouse management: a dedicated WMS moves stock physically while Business Central owns the inventory record. Receipts, put-aways, picks and shipments have to stay in step, and because warehouse operations are high-volume and time-sensitive, this is often where real-time or near-real-time integration genuinely earns its complexity.
• Third-party apps: payroll, tax, logistics, expense, document management and a long tail of specialist tools each need a slice of Business Central data. Many now ship with pre-built connectors, and where they do, using the vendor's supported connector beats hand-building a bespoke link that you then own forever. Part of good integration design is knowing when to buy the connection rather than build it.

8. Master data, idempotency and error handling: the unglamorous things that decide success

This is the section that separates integrations that quietly run for years from those that generate a steady drip of support tickets. None of it is glamorous, and all of it is decisive.

Master data is the foundation everything else stands on. An integration is a set of promises about matching records across systems: this customer here is that customer there, this item is that product. Those matches depend on stable, agreed keys and consistent data on both sides. If the customer master is duplicated, the item codes disagree, or two systems use different identifiers for the same thing, the integration will map records wrongly no matter how elegant the code. I have watched more integrations fail on messy master data than on any technical shortcoming. Before you integrate, you clean and align the master data and agree the system of record for each entity, because an integration built on shaky master data faithfully propagates the mess at machine speed.

Idempotency is the property that processing the same message twice produces the same result as processing it once. It sounds academic until you remember that real integrations retry: a network blip, a timeout, a redelivered webhook, and suddenly the same order arrives twice. Without idempotency, that becomes a duplicate sales order, a double payment, a doubled stock movement. The fix is to design every operation so that a repeat is safe, typically by carrying a stable unique identifier on each message and checking whether it has already been processed before acting on it. Idempotency is not optional decoration; it is the difference between an integration that shrugs off retries and one that corrupts your data the first time the network hiccups.

Error handling is where integrations reveal their true quality. The question is never whether an integration will encounter errors, it is what happens when it does. A well-built integration validates inputs, distinguishes transient failures (retry them, with sensible backoff) from permanent ones (do not retry, route them somewhere a human will see them), never silently swallows a failure, and keeps failed messages in a place where they can be inspected and reprocessed rather than lost. The worst integrations fail quietly, and the damage is discovered weeks later when the numbers do not add up. Build every integration to fail loudly and safely: loud so someone knows, safe so nothing is lost or corrupted while it waits to be fixed.

The honest limitation: these three disciplines are invisible in a demo. A happy-path integration that moves one clean record across a stable connection looks identical whether or not it has master-data alignment, idempotency and real error handling underneath. The difference only shows up under the messy, high-volume, failure-prone conditions of real operation, which is exactly when you cannot retrofit them easily. Budget for the unglamorous work up front, because it is the part that decides whether the integration survives contact with reality.

9. Governance, monitoring and versioning of integrations

An integration is not finished when it goes live; it is a running system that has to be operated, observed and evolved. The organisations whose integrations age gracefully are the ones that treat them as managed assets rather than fire-and-forget scripts.

Monitoring is the first non-negotiable. You need to know, without waiting for a user to complain, whether each integration is running, how many records it is moving, how many are failing and why. That means logging every run, alerting on failures and on silence (an integration that stops running entirely is often more dangerous than one that errors loudly), and giving someone clear ownership of watching it. The single most common way integrations cause damage is by failing silently while everyone assumes they are working. A dashboard nobody looks at is not monitoring; alerting that reaches a human who is responsible is.

Versioning is the discipline that keeps integrations alive through change. Business Central APIs are versioned deliberately so that Microsoft can evolve them without breaking existing consumers, and your custom APIs should follow the same practice: a stable versioned contract that consumers bind to, and a clear process for introducing a new version alongside the old rather than mutating the current one under everyone's feet. When you change an integration, you version the change, communicate it to whoever depends on it, and give them a window to move. Integrations break most often not because someone made a mistake but because someone made a change without treating the interface as a contract other systems rely on.

Governance ties it together: a register of what integrates with what, who owns each connection, what data crosses each boundary, and what the security scope of each integration account is. On a small estate this can be a single maintained document. On a larger one it becomes a genuine discipline with API management, access reviews and change control. Either way, the absence of governance is how an estate drifts into a state where nobody can say with confidence what is connected to the ERP or what would break if a given system changed. That uncertainty is itself a serious operational risk.

10. A practical approach to designing a durable integration

Pulling the threads together, here is the sequence I follow when designing an integration meant to last, rather than one meant to demo.

• Start from the business need, not the technology. What data has to move, in which direction, how fresh does it need to be, and what is the cost of it being wrong? Those answers determine the pattern. Do not pick real-time, event-driven or middleware first and fit the requirement to it afterwards.
• Agree ownership and the system of record for every entity. Before a line of code, settle who owns the customer, the item, the price, the order status. Ambiguous ownership is the root cause of most integration disputes, and it is a business decision, not a technical one.
• Clean and align master data. Match keys, resolve duplicates, agree identifiers. An integration is only as reliable as the master data it maps across, so this precedes the build.
• Choose the simplest pattern that meets the need. Batch over real-time, standard API over custom over page-based OData, point-to-point for a couple of links but middleware once the estate grows. Buy the vendor's supported connector where one exists.
• Secure it properly from day one. Service-to-service OAuth, a dedicated integration identity, least-privilege permissions, no human accounts and no static keys in config files.
• Build in idempotency and real error handling. Assume messages will be retried, duplicated and delivered out of order. Make repeats safe, separate transient from permanent failures, and keep failures visible and reprocessable.
• Instrument it before you ship it. Logging, failure alerts and silence detection are part of the build, not a later enhancement. If you cannot see it running, you do not control it.
• Version the interface and document the estate. Treat every API as a contract, introduce changes as new versions, and keep a living record of what connects to what and who owns it.

None of these steps is exotic, and that is the point. Durable integration is not a matter of cleverness; it is a matter of doing the ordinary things in the right order and refusing the shortcuts that feel harmless under go-live pressure. The teams whose integrations still run cleanly years later are not the ones who used the most advanced tooling. They are the ones who decided ownership early, cleaned their master data, secured properly, built for failure, and watched what they shipped. Whether Business Central is even the right hub for your estate in the first place is a question the is Business Central right for your organization pillar takes head on.

Final thoughts

Business Central gives you a serious, standards-based integration surface: a versioned REST API, flexible OData web services, custom APIs you shape in AL, OAuth security, webhooks, and a whole Microsoft stack of Power Automate, Logic Apps and Azure services sitting ready around it. The tools are good, and they are not where projects come undone. Projects come undone on the decisions that surround the tools: choosing a pattern more complex than the need, leaving master data messy, skipping idempotency, securing with a shortcut, and shipping without monitoring or a versioning discipline. Every one of those is a choice, and every one is within your control.

If there is a single idea to carry away, it is that integration deserves to be treated as a first-class part of the architecture, designed with the same care as the ledger, not bolted on in the last sprint before go-live. Get the ownership, the master data, the security, the failure handling and the monitoring right, and the integration layer becomes the quiet, reliable connective tissue that makes Business Central the trustworthy centre of your estate. Get them wrong and you spend years reconciling and firefighting. The technology will not decide which of those you get. The design discipline will.

Related reading: Business Central and the Microsoft ecosystem, Business Central and CMMS integration, Business Central and Power Automate, Business Central extensions and AL development, Azure OpenAI and custom AI agents for Business Central, Is Business Central right for your organization?.