HubSpot + QAD Adaptive ERP integration

QAD Adaptive ERP runs manufacturers in automotive, life sciences, food and beverage, consumer products and industrial manufacturing. QAD, founded in 1979, sells it as a cloud product on AWS, offers existing customers an upgrade path onto it through its Elevate program, and now pairs it with Redzone and Champion AI. The ERP holds the customer, the item and site, the sales order with its EDI traffic, and the invoice.

HubSpot comes in on the commercial side. Marketing and sales teams run campaigns, the pipeline and account planning there, and they keep needing what QAD knows: what each customer ordered, what is due to ship, and what is invoiced and still unpaid. Without a feed, that knowledge travels by spreadsheet and email, and it is stale by the time it lands. A seller preparing a quarterly review rebuilds the same picture by hand every time.

QAD’s integration story has moved quickly. Its Enterprise Platform exposes REST APIs, its Integration Platform adds standard APIs and a publish and subscribe mechanism, and a 2025 alliance embeds Boomi connectors in QAD software. What QAD does not do is publish the API reference openly, so the calls, the authentication and any limits come from your QAD documentation during discovery rather than from a public page.

Five records carry the relationship. Customers become HubSpot companies and their contacts become contacts. Items become products. Sales orders and invoices land as custom objects on the company, because an order book fed partly by EDI and OEM packages does not belong in a sales pipeline.

Everything moves into HubSpot in a first build. QAD owns the customer, the item, the price and every document, and those stay read only in the portal. A second phase can create a customer in QAD from a won deal, once the documentation confirms which API does it and a person approves each one.

Keys are QAD’s own codes, held in custom HubSpot properties: the customer code, the item number, and the order and invoice numbers. QAD’s Core Model shares one customer and one item across its applications, which is what makes those codes dependable keys. Contacts match on email, with the customer code as the tie breaker.

The shape is a polling watermark sync, with events as an accelerator where your release offers them. A service authenticates to QAD’s REST APIs as your documentation specifies, reads customers, items, orders and invoices changed since the last run, and batch upserts them into HubSpot on QAD’s codes, followed by a separate association pass. Watermarks live in the service, per record type, and per domain where the business runs more than one.

Where the Integration Platform’s publish and subscribe mechanism can notify an outside subscriber, the service subscribes and treats each event as a prompt to re-read that record through the API. The watermark sweep keeps running behind it to catch whatever an event missed. A reconciliation pass compares QAD and HubSpot counts on every run, and a replay endpoint re-reads any record type for a time range.

The deciding question is what your QAD release and licence expose, and it has to be answered from QAD’s documentation rather than assumed. A business on QAD’s cloud, one on an older release and one that already licenses Boomi each start from a different place.

A custom API integration over QAD’s REST APIs is the route we recommend. It holds the watermarks, the keys and the reconciliation in one service we run, and it can take events where they exist. An iPaaS is a genuine alternative here, because QAD embeds Boomi connectors in its software, so a business already running Boomi can host the flow there. There is no marketplace app to try first.

1. Scope. We read your QAD documentation with your administrator and confirm the release, the hosting, the domains and whether Boomi is already licensed.
2. Architect. We fix the keys, the watermark per record type, the event subscription if one exists, and the custom objects for orders and invoices.
3. Build. The service is written against a QAD test environment where you have one, and a HubSpot sandbox with a portal allowlist from the first commit.
4. Validate. We reconcile counts per record type and open order values against QAD reports, and replay a day of events to prove the sweep catches what they miss.
5. Operate. We watch run history, keep replay and reconciliation endpoints ready, and re-test the feed before every QAD upgrade.