Integrating Business Central Cloud With Third-Party Applications: REST APIs, Logic Apps and Enterprise Integration Patterns

Modern ERP rarely operates alone.

A Dynamics 365 Business Central environment may need to exchange data with an e-commerce platform, CRM, warehouse management system, payroll provider, expense solution, banking platform, EDI network, field-service application, product-information system, data platform or a custom industry application.

The technical challenge is usually not whether Business Central can exchange the data. It can, and Microsoft has invested heavily in making that straightforward.

The more important question is different.

How should the integration be designed so that it stays secure, traceable, duplicate-safe, supportable and resilient when something fails?

A point-to-point REST call is fine in a proof of concept. A production integration needs considerably more thought: API selection, authentication, inbound and outbound flows, synchronous versus asynchronous processing, schema validation, mapping and transformation, duplicate detection, sequencing, retries, dead-letter handling, reconciliation, monitoring, throttling, master-data ownership, conflict resolution, environment management and a support model.

This guide covers an enterprise approach to integrating Business Central Cloud with third-party solutions using REST APIs, Azure Logic Apps and the surrounding Azure integration services.

Start With the Architecture, Not the API Call

One of the most common integration mistakes is opening with the question "what endpoint should we call?"

The first question should be "what integration pattern is appropriate for this business process?"

A production architecture often looks like this.

The architecture does not need every component for every interface. A low-volume customer synchronization may need nothing more than a Logic App and a standard API. A high-volume EDI or e-commerce interface may justify API Management, Service Bus, Functions, detailed telemetry and a dedicated integration ledger.

The point is to select components deliberately, based on transaction volume, latency requirements, recoverability, security and who will support the interface at 7am on a Monday.

How Business Central Exposes and Consumes Data

Business Central offers several integration surfaces. The right one depends on what the interface has to do.

Standard REST APIs (API v2.0)

Use the standard APIs wherever they already meet the requirement. They cover customers, vendors, items, sales and purchase documents, journals, dimensions and a wide set of other business entities, and they are enabled by default for Business Central online.

The common endpoint for an environment follows this shape:

https://api.businesscentral.dynamics.com/v2.0/{environment}/api/v2.0/companies({companyId})/{entitySet}

Microsoft also documents a direct-tenant form that includes the user domain name before the environment name, which some tenants need. Either way, the environment name is part of the URI — one more reason environment configuration must never be hard-coded into integration logic.

Custom AL API pages

Reach for a custom API when the standard set genuinely does not fit:

• the entity you need is not exposed
• custom fields have to travel with the record
• the third party should get a stable, purpose-built contract rather than being coupled to standard Business Central structures
• the interface needs its own validation behaviour

This last point matters more than it first appears. Microsoft's documentation is explicit that extending the standard APIs with additional fields is not currently possible — if you need extra fields, you copy the AL and publish your own API page. That makes "standard API plus a couple of custom fields" a design that does not exist; it is a custom API.

A custom API page is an AL page with PageType = API and a small set of routing properties.

Those properties produce a route of this form:

https://api.businesscentral.dynamics.com/v2.0/{environment}/api/{publisher}/{group}/{version}/companies({companyId})/{entitySet}

API queries

An API query object generates a read-only endpoint that can join data across tables. It is a good fit for reporting-style extracts and lookups. It cannot be used to write data, and it is not webhook-enabled, so it is not a substitute for an API page on a read/write interface.

OData and SOAP web services

OData remains available and still has a place, particularly for older integrations. For new system-to-system work, API pages should be the default: Microsoft's own telemetry guidance recommends them over exposing UI pages as OData or SOAP endpoints, because API pages avoid the compute spent on UI elements the integration never uses. SOAP is on a deprecation path and should not be chosen for anything new.

The Business Central connector

The Business Central connector is available to Azure Logic Apps as a standard-class connector, and to Power Automate, Power Apps and Copilot Studio as a premium connector. It provides triggers for when a record is created, modified, deleted or changed, and actions to get, find, create, update and delete records, plus running a Business Central action.

Two published constraints are worth designing around: the connector is throttled at 300 API calls per connection per 60 seconds, and any single record it handles must be under 8 MB.

Azure Functions

Functions are useful for transformations that become unwieldy in a Logic App: complex mapping, reusable integration libraries, specialized validation, cryptographic work or format conversion such as EDI and fixed-width files.

Azure Service Bus

Service Bus matters when reliability is more important than an immediate synchronous answer — e-commerce order ingestion, EDI, warehouse transactions and high-volume journal imports. It gives you durable buffering, controlled consumption, and a dead-letter queue you can actually operate.

Standard API or Custom API?

Before writing AL, confirm the standard API does not already meet the requirement.

Do not build custom AL merely because custom development is possible.

Every custom API becomes something that has to be governed, tested, versioned, documented and maintained across upgrades. That cost is worth paying when the contract genuinely needs to be yours — and pure overhead when it does not.

Inbound Integration: Third Party Into Business Central

Inbound integration means another application sends data into Business Central: Shopify orders, CRM customers, WMS shipment confirmations, payroll journals, employee expenses, banking transactions, EDI orders, product-information updates.

The Logic App should never simply accept a payload and forward it to Business Central.

Before Business Central receives the transaction, validate:

• mandatory fields and data types
• currency codes and exchange-rate assumptions
• customer and vendor identifiers
• item references and units of measure
• company mapping, where the tenant has more than one company
• dates, including timezone handling
• duplicate transaction identifiers
• source-specific business rules

Each of those checks needs a defined exception path. "The Logic App failed" is not an exception path; a message on a reviewable error queue, with the payload, the reason and the source record id attached, is.

Outbound Integration: Business Central Into Third Party

Outbound flows push data the other way: customer updates to CRM, item data to e-commerce, shipment confirmation to a marketplace, invoice data to a customer portal, inventory levels to a warehouse.

The webhook-driven pattern

Business Central supports webhook subscriptions on supported entities. A subscriber registers a notificationUrl and a resource path, and completes a validation-token handshake before the subscription becomes active.

POST https://{businessCentralPrefix}/api/v2.0/subscriptions
Content-Type: application/json

{
  "notificationUrl": "https://{yourEndpoint}",
  "resource": "/api/v2.0/companies({companyId})/customers",
  "clientState": "opaque-shared-secret"
}

Four documented behaviours shape the design.

Notifications are signals, not payloads. A notification carries the subscription id, the resource path, the change type and a last-modified timestamp — not the record. The integration reads the current version of the record from the resource path it was given. That is a feature: it means you always act on current state rather than a stale snapshot.

Subscriptions expire after three days. Renewal is a PATCH, and it requires the same validation-token handshake as creation. Renewal has to be part of the running solution, monitored like anything else.

High-volume changes collapse into a collection notification. Business Central waits a short delay after the first change to an entity before notifying. If more than 1,000 records change inside that window, a single collection notification is sent with a filter on the resource instead of one notification per record — so the subscriber must be able to handle a filtered set, not just single records.

A badly behaved endpoint loses its subscription. If Business Central cannot reach the subscriber, it retries over the next 36 hours — but only when the subscriber responds with 408, 429 or a 5xx status. Any other response code stops the retries and the subscription is deleted. An endpoint that answers 500 while it is unhealthy keeps its subscription; one that answers 200 and quietly drops the message does not get retries at all.

Scheduled incremental synchronization

The second outbound pattern is a scheduled job that queries changed records and moves them on. It is slower than a webhook and much easier to reason about during recovery, which is why mature architectures usually run both: webhooks for latency, a periodic reconciliation pass for completeness.

Webhooks or Polling?

Neither is universally better.

Webhook support has real boundaries. Business Central does not send notifications for API queries, for pages over temporary or system tables, or for pages with composite keys — and there is a documented ceiling on the number of webhook subscriptions per environment. Check that the entity you are designing around is actually supported before the pattern becomes an assumption.

Synchronous or Asynchronous?

Synchronous integration is the right answer for lookups, validations and small interactive transactions where the user is waiting for an answer. The trade-off is coupling: if Business Central is slow or throttled, the source system is slow or failing too.

Asynchronous integration is usually better for high-volume orders, EDI, warehouse events, large journals and anything non-interactive. The source hands the transaction to a queue, gets an acknowledgement immediately, and downstream processing continues at a controlled rate.

Design a Canonical Data Flow

Third-party applications and Business Central rarely use the same names for the same concepts.

A source payload might arrive looking like this:

{
  "orderId": "WEB-10382",
  "customerId": "CUST-1001",
  "currency": "CAD",
  "lines": [
    { "sku": "ITEM-100", "qty": 4, "price": 29.95 }
  ]
}

And leave the mapping layer as something Business Central understands:

{
  "customerNumber": "CUST-1001",
  "externalDocumentNumber": "WEB-10382",
  "currencyCode": "CAD"
}

For every field, the design should state the source, the target, the data type, whether it is required, the transformation, the default, the validation, the source of truth and the failure behaviour.

Make the mapping a formal specification

The field-level mapping document is part of solution design, not a developer's scratch file.

That table becomes the shared contract between business analysts, Business Central consultants, integration developers, source-system owners, testers and — eventually — whoever supports the interface.

Duplicate Detection and Idempotency

Duplicate prevention is not a refinement. It is the difference between an integration you can retry and one you cannot.

Consider an e-commerce platform sending order WEB-100234. Business Central creates the order. The network times out before the source receives the response. The source retries.

Without idempotency, that is now two sales orders for one customer order — and nobody notices until someone ships twice.

The fix is a deterministic integration key, calculated before any work happens:

integrationKey = sourceSystem + ":" + sourceRecordId

Shopify:WEB-100234
CRM:a4f19c02-...
WMS:SHP-8842

Useful controls include the source transaction id, the external document number, composite keys where a single identifier is not unique, Business Central system ids, payload hashes for change detection, and a dedicated integration ledger that records the outcome.

Use an integration transaction ledger

For enterprise integrations, keep a durable record of every transaction that crossed the boundary.

That ledger is what lets an operations team answer, without escalating: did order 100234 reach Business Central, was it processed twice, which document was created, why did it fail, how many times did we retry, and did somebody already replay it?

Classify Failures Before You Retry

A production integration should decide what kind of failure it is looking at before it decides what to do.

Retrying a validation failure forever is one of the most common causes of a queue that never drains.

Retry, Backoff and Dead-Letter Handling

Repeated immediate retries make an outage worse rather than better, which is why Microsoft's own guidance for handling HTTP 429 from Business Central is explicit that the client must retry with a cool-off period — regular intervals, incremental intervals, exponential backoff or randomization.

If you are orchestrating in Logic Apps, much of this is built in. Logic Apps retry policies fire on 408, 429 and 5xx responses, and the default policy is an exponential-interval policy of up to four retries; you can also select fixed-interval, exponential or no retry, and set the count and interval explicitly. Beyond the individual action, runAfter settings and scopes give you a place to catch a whole block of failures and handle them once.

A well-behaved retry model should:

• distinguish retryable from non-retryable errors
• respect the platform's throttling signals — Business Central attaches a retry-after header on 502 and 503 responses, and that header should be honoured rather than ignored
• preserve the same integration key across every attempt
• cap the number of attempts
• expose retry status to operations rather than burying it in logs

When retries are exhausted

The transaction must not disappear. Azure Service Bus dead-letters messages automatically when the maximum delivery count is exceeded (the default is 10) or when the message time-to-live expires, and an application can dead-letter a message explicitly with a reason and description. Dead-lettered messages sit in a sub-queue addressed as /$deadletterqueue, they are never cleaned up automatically, and they can be inspected and resubmitted.

Support teams should be able to see the original source record, the payload, the failure reason, the number of attempts, the last response, the integration id and any related Business Central record — without needing developer access.

Authentication and Security

For unattended system-to-system integration, use Microsoft Entra application authentication with the OAuth 2.0 client credentials flow. Microsoft's guidance is direct about why: delegated flows can be subject to multifactor authentication, which makes them unsuitable for an unattended integration.

The setup has two halves. In Microsoft Entra ID you register an application, create a client secret or certificate, and grant it the Business Central application permission — API.ReadWrite.All for APIs and web services, Automation.ReadWrite.All for the automation APIs. In Business Central you then register that application's client id on the Microsoft Entra Applications page, enable it, and assign permission sets.

POST https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id={clientId}
&client_secret={clientSecret}
&scope=https://api.businesscentral.dynamics.com/.default

Security design should include:

• a dedicated Entra application registration per integration, not one shared identity for everything
• least-privilege Business Central permission sets — note that Business Central will not allow an application to be assigned SUPER, so least privilege is enforced, not merely recommended
• separate identities where different interfaces need different privileges
• secrets and certificates held in Azure Key Vault, never in workflow definitions or source control
• a credential rotation schedule that someone owns
• environment separation, so a sandbox credential cannot reach production
• access auditing

Never hard-code client secrets, access tokens or user credentials. That includes "temporarily", in a sandbox, during a proof of concept.

API Management as a Governance Layer

Where several external systems integrate with Business Central, Azure API Management gives you a single controlled entry point that can centralize authentication, rate limiting, API versioning, policy enforcement, IP and network restrictions, logging and backend abstraction.

The abstraction matters as much as the control. With API Management in front, the third party integrates with your contract rather than with a Business Central URL — so the environment name, the API version and even the choice between a standard and a custom API can change without renegotiating with an external partner.

Define the System of Record

Bidirectional integration becomes dangerous the moment two applications both believe they own the same data.

For composite records, ownership has to be defined at field level. A customer is rarely owned by one system: the relationship data belongs to CRM, while credit limits, payment terms, invoices and balances belong in Business Central. Agreeing that boundary is a business decision, not a technical one — but leaving it unmade is a technical disaster.

Prevent integration loops

Once ownership is settled, the next hazard is circular updates:

CRM updates the customer
        |
        v
CRM  ->  Business Central
        |
        v
Business Central update fires a webhook
        |
        v
Business Central  ->  CRM
        |
        v
CRM updates again  ...

Without controls, the same change circulates indefinitely. Useful brakes include a source-system marker on the record, a correlation id carried through the whole chain, a dedicated integration user or application identity whose changes are recognized and suppressed, a change-origin field, a payload or change hash so an update that changes nothing is not propagated, and ownership rules that simply refuse to write fields the other system owns.

Sequence dependent transactions

Some transactions depend on others existing first:

Customer  ->  Ship-to address  ->  Sales order header  ->  Sales lines  ->  Shipment / payment

What happens when the order arrives before the customer? Answer it during design, not during hypercare. The realistic options are ordered queues (Service Bus sessions), explicit dependency checks with a hold-and-retry status, or controlled creation of the prerequisite record — each with different implications for master-data quality.

Incremental Synchronization and Watermarks

Downloading every record every few minutes is rarely a good long-term strategy. Where an endpoint exposes a reliable modified timestamp, use an incremental pattern.

Do not advance the watermark until the intended processing is actually complete.

That single rule prevents the most damaging class of silent integration failure — the one where the job reports success every night and quietly skips whatever failed.

Pagination, Filtering and Throttling

Do not assume one API response contains every record. Business Central paginates results and clients are expected to follow the continuation link until there are no pages left. A client that reads the first page and stops will look like it is working for months.

Filtering and shaping the request is not a micro-optimization either — it is how you stay inside the platform's limits. Microsoft's guidance for reducing API calls is to use webhooks instead of aggressive polling, batch operations where appropriate, apply server-side $filter rather than pulling whole datasets, use $expand to fetch related entities in one request, and use deep inserts to create a document and its lines in a single POST.

The published operational limits are worth designing against explicitly:

There is also a scaling technique that is easy to miss: Microsoft notes that operational limits apply per user, that service principals are treated the same as any other user, and that throughput can be increased by distributing work across multiple users or service principals rather than funnelling everything through one identity.

Optimistic Concurrency

An integration should have an answer for what happens when a record changes between the read and the update.

Business Central returns an @odata.etag with entities, and update requests carry an If-Match header. Sending the etag you read means the update fails if the record has moved on; sending If-Match: * means you will overwrite whatever is there. The second form is convenient, and it is exactly how a CRM update silently reverts a credit-limit change a controller made ten seconds earlier.

For important master data, decide deliberately whether a conflict should fail, retry after re-reading, merge, or route to a human. HTTP 409 and 412 responses are the signals that this has happened, and they should be classified as concurrency events rather than lumped in with generic errors.

High Volume Needs Backpressure

A source application can produce transactions faster than Business Central should consume them. This is not a sound pattern:

10,000 incoming orders
        |
        v
10,000 simultaneous API calls

A queue turns an uncontrolled burst into a controlled rate:

Incoming orders
        |
        v
Service Bus queue          (durable buffer)
        |
        v
Controlled consumers       (bounded concurrency)
        |
        v
Business Central API

Design explicitly for concurrency limits, throttling responses, retry behaviour, queue depth alerting, backpressure to the source where it can accept it, and — the one people forget — catch-up behaviour after downtime. A queue that has absorbed four hours of orders will try to drain them, and it needs to do so without triggering the throttling that caused the outage in the first place.

Monitoring, Correlation and Observability

The integration is not complete when the API returns a success code.

Operations teams should be able to see transactions received, processed, failed and pending; duplicates prevented; retry and dead-letter counts; average processing time; and the timestamp of the last successful transaction and the last successful synchronization for each interface.

Business Central contributes real telemetry to this picture. When an environment is connected to Azure Application Insights, every incoming web service request emits a trace with the endpoint, HTTP method, HTTP status code, category (API, OData or SOAP), the AL object and extension behind the endpoint, the query filter used, time spent queued, server execution time, SQL statements executed and rows read, and — on failures — a failure reason and diagnostics message.

Two request headers make that telemetry far more useful:

• setting client-request-id on the call also sets the operation id in Application Insights, which is what lets you correlate a Business Central trace with the Logic App run and the source system event
• setting User-Agent lets you tell which caller is responsible for which traffic, which becomes essential the moment more than one integration shares an environment

Carry one correlation id across the source system, API Management, the Logic App, Service Bus, Business Central and the target system. Without it, investigating a single failed order means correlating five tools by timestamp.

Reconciliation Is Not Monitoring

Monitoring asks whether the technical process executed. Reconciliation asks whether both systems ended up with the intended business result. They are different questions, and an integration can be comprehensively green while the numbers do not agree.

Source orders                     10,248
Messages accepted                 10,248
Business Central orders created   10,242
Failed                                 6
Replayed after correction              6
Final Business Central orders     10,248
Unexplained difference                 0

Run that comparison on a schedule, publish it where finance and operations can see it, and define who is accountable for a non-zero difference. For financially significant interfaces, reconciliation output belongs in the month-end process rather than in a monitoring dashboard nobody opens.

Environments, Testing and Cutover

Environment strategy

A workable lifecycle runs development, Business Central sandbox, integration test, UAT and production — with separate configuration at every stage for the environment name, company id, API base URL, credentials, Service Bus namespace, webhook endpoints, monitoring destination and retry rules.

Environment-specific values are configuration. They are never business logic, and they are never literals inside a workflow definition.

Integration testing

A complete test plan covers far more than the happy path:

• valid transactions and expected variants
• missing required fields, invalid references, malformed payloads
• duplicates, and resend after a timeout
• invalid credentials and insufficient permissions
• throttling behaviour under load
• a Business Central outage, and a third-party outage
• retry exhaustion, dead-letter creation, and replay
• duplicate-safe replay specifically
• sequencing problems
• volume and load
• reconciliation accuracy
• security testing and UAT business scenarios

Cutover

Integration cutover deserves its own runbook: freeze the legacy interface, capture the final delta, process remaining in-flight transactions, reconcile, switch endpoints and credentials, enable the new integration, and run hypercare monitoring with agreed metrics.

Before go-live, four questions need written answers. What happens to in-flight messages? What is the rollback process? Who approves the reconciliation result? Who owns failures during hypercare?

Three Worked Patterns

E-commerce orders into Business Central

Orders arrive at API Management, pass through a Logic App that validates the schema, maps the customer and SKU, checks the currency, creates the integration key and performs the duplicate check, then land on a Service Bus queue. A controlled processor drains that queue into the Business Central sales order API and writes the outcome to the integration ledger.

The benefit is specific: if Business Central is unavailable, the e-commerce platform does not have to stop taking orders. The queue absorbs the interruption and consumers resume when the environment is back.

WMS and Business Central

A warehouse interface is usually bidirectional. Business Central sends released orders, items, quantities, ship-to details and requested dates; the WMS returns picked quantity, shipped quantity, tracking number, shipment date and exceptions.

The design has to address partial shipments, unit-of-measure conversion, duplicate shipment events, cancellation after release, sequencing, warehouse rejection and inventory reconciliation — most of which only surface in testing if somebody deliberately tests for them.

CRM and Business Central

A common split gives CRM the prospect and relationship data, contacts and opportunity context, and gives Business Central the financial customer setup, credit control, payment terms, invoices and balances.

The two decisions that matter are exactly when a CRM account becomes a Business Central customer, and which fields flow in which direction after that point.

What a Production-Ready Integration Should Not Do

Avoid designs that:

• hard-code credentials, or assign excessive permissions
• poll full tables every few minutes
• retry forever, or retry failures that cannot succeed
• create records without idempotency
• assume a timeout means Business Central did nothing
• advance watermarks before processing is complete
• expose Business Central directly to uncontrolled clients
• rely on a single document number where the source can reuse it
• let two systems update the same data without ownership rules
• send every transaction straight through regardless of load
• omit dead-letter handling, reconciliation or correlation ids
• hide failed messages in technical logs operations cannot interpret
• build a custom AL API where a suitable standard API already exists

Business Central Integration Design Checklist

Business. What process is being integrated? What is the source and the destination? Which system owns each data domain? What latency is acceptable? What volume is expected? What happens during an outage?

Data. What is the field mapping? Which keys identify records? How are duplicates detected? What transformations are required? How are code mappings governed over time?

Technical. Standard API or custom API? Synchronous or asynchronous? Logic Apps, Functions or both? Is Service Bus required? Are webhooks appropriate and supported for the entity? Is API Management required? How are pagination and throttling handled?

Security. Which Entra application is used? Which Business Central permission sets are assigned? Where are secrets stored? How are credentials rotated? Is least privilege genuinely enforced?

Operations. How are failures monitored? How are dead-letter messages reviewed and replayed? How is duplicate-safe replay guaranteed? What is the reconciliation process? Who owns support?

Deployment. Which environments exist? How is configuration promoted? What is the cutover plan? What is the rollback plan? What are the hypercare metrics?

Conclusion

Integrating Business Central Cloud with third-party applications is straightforward at the API level. Designing the integration so it stays reliable in production is where the real architecture work begins.

REST APIs provide the contract. Logic Apps orchestrate validation, transformation and routing. Service Bus decouples high-volume or failure-sensitive transactions. API Management adds governance and security. Application Insights and an integration ledger provide the traceability you will want on the first bad day after go-live.

But the decisive questions are business questions:

• Which system owns the data?
• What makes a transaction unique?
• What happens when it arrives twice?
• What happens when Business Central is unavailable?
• How is a failed message recovered?
• How do we prove both systems ultimately agree?

A production-grade Business Central integration is designed for failure, replay, reconciliation and supportability from day one.

Further Reading

Microsoft documentation

• Business Central API (v2.0) endpoints
• Developing a custom API page in AL
• Service-to-service authentication for Business Central
• Working with webhooks in Business Central
• Working with API rate limits
• Operational limits for Business Central online
• Web service request telemetry
• Dynamics 365 Business Central connector reference
• Handle errors and exceptions in Azure Logic Apps
• Azure Service Bus dead-letter queues

On this site

• Dynamics 365 Business Central overview
• Business Central implementation guide
• Microsoft Azure services
• Microsoft Power Platform
• ERP integration best practices
• ERP implementation services
• Managed support for Dynamics 365