Business Central API integration is one of the most common requests I encounter from clients — and one of the areas where technical decisions made early have the longest-lasting consequences. BC doesn't live in isolation. It connects to eCommerce platforms, logistics providers, payment processors, data warehouses, and a growing range of cloud services. Getting those connections right requires more than knowing the API surface; it requires understanding how BC handles data consistency, error recovery, and volume across its update cycles.
The Main Integration Patterns
Most BC integrations fall into a handful of patterns, and the right choice depends on what you're connecting to and what the integration needs to do.
BC's Native API (OData and Custom APIs)
Business Central exposes a set of standard OData endpoints, and developers can publish custom API pages to expose exactly the data an external system needs. This is the cleanest approach when the external system can consume REST endpoints — it's supported by Microsoft, survives upgrades well, and gives you control over what gets exposed without touching the core application.
For eCommerce integrations, I've used this pattern extensively: surfacing inventory levels, pricing, and order data through custom API pages, then building the sync logic on top. The key design decision is whether the integration is event-driven (BC pushes on change) or polling-based (external system pulls on a schedule). Both work; polling is simpler but generates unnecessary load at scale.
File-Based Integration via SFTP
Not every external system speaks REST. Older ERP integrations, logistics partners, and some banking systems still operate on file exchange — flat files dropped to an SFTP server on a schedule. I've built these integrations using WinSCP automation from within BC's AL layer, handling structured file formats on both the inbound and outbound sides. It's less elegant than API-to-API, but it's reliable and widely supported.
Azure Service Bus and Event-Driven Architecture
For higher-volume or more complex integration scenarios, Azure Service Bus provides a message queue that decouples BC from downstream systems. BC publishes events to the queue; consuming services process them asynchronously. This pattern handles spikes gracefully and makes the overall architecture more resilient — if a downstream system is temporarily unavailable, messages queue rather than fail.
Direct Database Queries and .NET Interop
Some legacy integrations require reaching outside BC's standard data layer entirely — querying an external SQL database directly, for instance, or calling a .NET library that has no REST equivalent. AL supports .NET interop in on-premise deployments, and I've used it for cases where the integration target simply doesn't expose an API. These are the integrations that require the most careful documentation, since they tend to be the ones future developers find most opaque.
What Makes Integrations Fail
In my experience, most integration failures aren't caused by the initial build. They're caused by insufficient error handling, inadequate logging, and missing retry logic. An integration that works in normal conditions but silently swallows errors under load is worse than one that fails loudly — because silent failures cause data drift that takes weeks to detect and reconcile.
Every integration I build includes structured error logging, alerting on repeated failures, and a documented recovery procedure. That operational thinking is as important as the technical implementation.
If you're evaluating BC integration work and want a developer who has handled both modern API and legacy file-based scenarios across multiple production environments, reach out to discuss your requirements. Related reading: how AL extensions work — most integrations are delivered as extensions that live alongside your BC customizations.