HubSpot + Dynamics 365 Business Central integration

Business Central holds the quote, the order and the posted invoice, with real webhook subscriptions and an Entra identity already in the building.

Native app

Scope this integration Book a scoping call

Dynamics 365 Business Central HubSpot

customers Company

salesQuotes Deal

salesOrders Deal

salesInvoices Custom object

items Product

Into HubSpot
Two way

Is there a native Dynamics 365 Business Central + HubSpot integration?

Yes. Microsoft Business Central has a HubSpot-built app in the HubSpot App Marketplace as of September 2026, and it keeps customer records in step without a build. It does not carry sales orders or posted invoices. Those need a keyed service on API v2.0 with webhook subscriptions, which we scope at 70 to 150 build hours.

Recommended route: Custom middleware
Build effort: 70 to 150 hours
In the HubSpot App Marketplace?: Yes, Microsoft Business Central by HubSpot
Typical elapsed time: 4 to 8 weeks

Marketplace checked September 2026.

Why teams connect Dynamics 365 Business Central to HubSpot

Business Central is the ERP a Microsoft shop already owns. The finance team is in it, the identity is already in Entra, and the same administrator who manages mailboxes can grant an integration access in an afternoon. That last fact is worth more than it sounds, because on most ERP projects the slowest step is getting credentials from somebody who does not want to issue them.

What brings people to this page is usually a quoting problem. Quotes and orders live in Business Central, pipeline lives in HubSpot, and the two disagree by a day or a week. The sales leader is forecasting from HubSpot while the finance team is reporting from Business Central, and the numbers never match closely enough for either of them to trust the other. Everybody has already tried fixing it with discipline. It does not work, because the disagreement is structural rather than behavioural.

There is a second group, and they arrive with a longer history. A large share of Business Central estates are upgraded Navision installations carrying a decade of customization, some of it exposed through custom API pages and some of it not exposed at all. For them the interesting question is which of their fields made it into the API surface, not whether the API exists at all. That is a discovery question with a concrete answer, and it is the first thing we check.

What syncs

Five entities do the work. Customers become HubSpot companies, sales quotes open deals, sales orders update the deals their quotes opened, posted sales invoices land on a custom object, and items become products.

The quote to order chain is the part worth getting right. A quote and the order it becomes are two records in Business Central and one deal in HubSpot. If the order opens its own deal, every won opportunity appears twice and the forecast doubles. We carry the originating quote number on the order and key the write on it, so an order updates the deal rather than opening another.

Everything keys on the document number held in a custom HubSpot property, never on a name. Customer names change; customer numbers do not. Posted invoices sit on a custom object rather than on the deal, because an invoice has a balance and an ageing bucket while a deal has a stage and a close date, and collapsing the two gives you a pipeline that reopens on every credit memo.

Objects that sync between Dynamics 365 Business Central and HubSpot
Source object	HubSpot object	Direction	Match key	Notes
customers	Company	Two way	Customer number held in a custom HubSpot property	The customer number survives a rename. The display name does not.
salesQuotes	Deal	Into HubSpot	Quote number	The closest thing Business Central has to a pipeline record.
salesOrders	Deal	Into HubSpot	Order number, carrying the quote number it came from	An order updates the deal its quote opened rather than creating a second one.
salesInvoices	Custom object	Into HubSpot	Invoice number, associated to the order
items	Product	Into HubSpot	Item number

Architecture

A webhook queue, which is the shape Business Central actually supports rather than one we impose. The service registers a subscription per resource, answers the validation handshake, and receives a notification carrying the resource path and the change type whenever an entity moves.

Notifications go onto a queue by entity identifier. A worker reads the full record from API v2.0 and writes it into HubSpot as a batch upsert keyed on the document number, and a separate pass makes the associations. That split is what makes replay safe, because both halves are idempotent.

Two pieces of state matter. A keeper job renews every subscription before its three day expiry, completing the handshake again each time. And a watermark sweep runs nightly against the last modified timestamp, reconciling what the queue processed against what actually changed. Webhooks are fast, and a sweep behind them is what makes the feed trustworthy.

The source system raises a webhook, the service queues the event and writes the HubSpot record, so a change lands in seconds and a failed event is retried rather than lost.

What the API allows

API style: REST
Authentication: OAuth 2.0
Webhooks: Yes
Changed-since filter: Yes
Sandbox: Yes
Rate limit: 600 OData requests a minute per production environment, 300 per sandbox, and 6,000 per user in a five minute sliding window

Developer documentation learn.microsoft.com

Three ways to connect

The deciding question here is whether sales documents are in scope. If the answer is no, and you only want account records to agree, HubSpot’s own Business Central app does that with nothing to host. It is a field sync, so quotes, orders and posted invoices are outside it.

If sales documents are in scope, build. Business Central gives a service almost everything it needs: real subscriptions, a clean application identity, and generous request limits. The route to avoid is a per-task automation platform, partly on cost and mostly on throughput. The rate limits that matter are counted per user, and an automation identity shared across several flows will throttle all of them together at exactly the moment a bulk posting run makes things busy.

Custom middleware
Recommended
Business Central publishes proper webhook subscriptions and a clean application identity, so a keyed service can carry quotes, orders and posted invoices at near real time without polling the environment flat.
Native app
Possible
HubSpot's own Business Central app keeps customer records in agreement with no build, which is the right answer for a team that wants the account record right and nothing more.
Automation platform
Avoid
A per-task platform spends the environment's request budget on connector overhead, and the per user rate limit means one busy automation identity throttles every other integration using it.

What breaks and how we prevent it

Expired and deleted subscriptions

Expired subscriptions are the quiet failure. A subscription lasts three days, and a renewal that does not complete the handshake does not count. Worse, if our endpoint fails with anything other than a timeout, a too many requests or a server error, Business Central stops retrying and deletes the subscription outright. We return the safe codes deliberately on failure, and we alert when a subscription count drops rather than when data stops arriving.

Month end bulk postings

Bulk postings break a naive design. A month end run changes thousands of records in seconds, and the response is a single collection notification with a filter rather than a notification per record. A service that only understands per-record events silently misses the busiest day of the month. We handle the collection type explicitly and read the filtered page.

Permissions assembled by hand

An application identity cannot hold the full administrator permission set, so the permissions are assembled by hand and it is easy to grant read but not the object a document line needs. We test every entity in a sandbox with the production permission set, not with an administrator.

Two major updates a year

Business Central takes two major updates a year, and custom API pages can move underneath an integration. We pin the API version in every path, run the sandbox on the preview release, and treat a schema difference as a release task rather than an incident.

Our approach

Scope. We check which fields are exposed through the API surface, which are locked in customization, and whether sales documents are genuinely in scope.
Architect. We fix the quote to order rule, the keys, the subscription list and the sweep window before anything is written.
Build. Development runs in a sandbox environment with an environment allowlist in the service from the first commit.
Validate. We reconcile customer, order and invoice counts against a Business Central report, and run a month end in the sandbox to prove the collection notification path.
Operate. Cutover swaps the credentials and the environment. After that we watch subscription health, keep the replay and reconciliation endpoints available, and re-test against each release wave in the sandbox first.

Common questions

Is the Microsoft Business Central app in the HubSpot marketplace built by HubSpot?

Yes. The listing named Microsoft Business Central is published by HubSpot, and a separate connector from Cloudify sits beside it. The HubSpot app is a field level sync for account records. Sales documents and posted invoices are not part of it, so anything transactional still means a build.

How do Business Central webhook subscriptions stay alive?

They have to be renewed. A subscription expires after three days, and renewing it means sending an update request and completing the same handshake as the original registration, returning the validation token with a success code. We run a keeper job daily rather than hourly before expiry, so a single failure has two more chances before anything lapses.

What happens when Business Central sends a collection notification?

It means too much changed at once. Business Central waits about thirty seconds after the first change, and if more than a thousand records moved in that window it sends one collection notification with a filter instead of a notification per record. Our service reads the filtered page rather than guessing, which is why a bulk posting run does not flood the queue.

Does a Business Central integration need a licensed user?

It needs an application identity rather than a person. Service to service authentication registers an application in Microsoft Entra, grants it API access, and enables it inside Business Central with explicit object permissions. Applications cannot be given the full administrator permission set, so the permissions have to be chosen deliberately, which is a good constraint rather than an obstacle.

How many API calls can a Business Central environment take per minute?

Six hundred OData requests a minute against a production environment and three hundred against a sandbox, with a separate per user ceiling of six thousand requests in a five minute sliding window. Exceeding either returns a too many requests response. A batch request may hold one hundred operations, which is the cheapest way to stay inside both.

Can we build against a Business Central sandbox first?

Yes, and we always do. Essential and Premium subscriptions include one production environment and three sandbox environments at no extra charge, and a sandbox can be created as a copy of production. We build and rehearse there, then cut over by swapping credentials, with an environment allowlist in the service so the wrong token cannot write.

Why would a Business Central order create a second deal in HubSpot?

Because the order was written on its own key instead of the quote it came from. Business Central holds a quote and an order as two records, so a naive sync opens a deal for each and the forecast doubles. We carry the originating quote number onto the order and upsert on it, so the order updates the deal the quote opened.

What does a Business Central and HubSpot integration take to deliver?

Allow 10 to 20 hours of discovery and 70 to 150 hours of build for five entities with webhook subscriptions, a renewal keeper, a nightly sweep and reconciliation endpoints. Discovery is where the quote to order rule and the exposed field list get settled. Calendar time depends less on us than on how quickly an administrator can register the application in Entra.