HubSpot + Acumatica integration

Acumatica sells one system for most of a small or mid-sized business: financials, distribution, manufacturing, project accounting, and a CRM that Acumatica describes as unified with the ERP. Its own documentation notes that many of its users run HubSpot for marketing, so a company running both has two places an account lives. The friction shows up as questions nobody in sales can answer. Has the last order shipped? Is the account on credit hold? Which invoice is still open before the renewal call?

Acumatica’s design makes the account question sharper than on most ERPs. A prospect starts as a business account and is extended into a customer, which Acumatica does automatically when a sales order is created from an opportunity or a sales quote. The account keeps one status list throughout, from Prospect through Credit Hold to Inactive. So the ERP already holds the account HubSpot is chasing, and the two systems start to disagree the moment either side edits it.

HubSpot and Acumatica each publish an answer for that CRM half: HubSpot’s Acumatica CRM app, and a HubSpot connector built into Acumatica itself. Both move accounts, contacts and leads. What they leave out is everything after the order, and that is where the questions above live: open orders on the company record, shipment status beside the deal, an overdue invoice flagged before a seller quotes again.

The build carries five objects, all one way. Customers become HubSpot companies, sales orders become deals, shipments and invoices land on custom objects associated to their orders, and stock items become products. Accounts, contacts and leads stay with whichever CRM-level sync you already run, and the build writes only the ERP fields, so the two never fight over a property.

Keys come from Acumatica’s own key fields, the ones its REST API puts in the URL. A customer keys on its customer ID. A sales order keys on its order type plus its order number, never the number alone, because Acumatica addresses an order by the pair. An invoice keys on its document type plus its reference number, the two key boxes on the Invoices and Memos form, and the type also keeps a credit memo from being read as an invoice. A shipment keys on its shipment number and associates to every order it covers, since one shipment can ship several sales orders.

Acumatica owns the order, the shipment and the invoice, and a sales tool that edits a released document creates work for finance. Where a write back is wanted, the usual first one is a closed won deal creating the sales order, and we hold it behind a review step.

The shape is a webhook queue with a sweep behind it, and Acumatica supplies both halves. For each object, a generic inquiry lists the fields worth watching, and a push notification points that inquiry at our HTTPS endpoint, with a header value we check on arrival. When a transaction changes the inquiry’s results, Acumatica posts JSON holding the inserted and deleted rows, the tenant, a transaction id and a timestamp.

The endpoint acknowledges at once and queues the notification by transaction id, which Acumatica provides so a consumer can drop duplicates. A worker reads the full record by its key fields through the contract-based REST API, pinned to one endpoint version such as Default/25.200.001, and upserts HubSpot in batches keyed on the Acumatica key. A separate pass associates shipments and invoices to their orders, so replaying a batch changes nothing.

Behind the queue, a scheduled sweep asks each entity for records whose LastModified value is later than the stored watermark, which catches whatever a failed notification lost. The service signs in as an OAuth 2.0 connected application, never with a user name and password.

What decides the route on Acumatica is how far past the account record the question goes. If sellers need accounts, contacts and leads to agree and nothing more, two packaged options already exist. HubSpot’s Acumatica CRM app runs inside HubSpot, connects through a connected application registered in Acumatica, and syncs business accounts, contacts and leads both ways. Acumatica’s own connector runs inside Acumatica on import and export scenarios and adds marketing lists, with one HubSpot account per Acumatica instance. We run one of them, never both, because each writes the same records.

Once orders, shipments or invoices are in scope, the choice is a custom API integration or an iPaaS. An iPaaS signs in as one more API user, and the licence caps API users, concurrent requests and requests per minute across every integration on the instance. A dedicated service spends that allowance deliberately, and it is the route we recommend.

1. Scope. We settle which CRM-level sync owns accounts, contacts and leads, then list the order, shipment and invoice fields sellers use.
2. Architect. We fix the keys, the generic inquiry per object, the endpoint version and the LastModified watermark, and write them down.
3. Build. The service is built against a test tenant with its own connected application and a portal allowlist from the first commit.
4. Validate. We replay a day of notifications, run the sweep, and reconcile order and invoice counts against an Acumatica report.
5. Operate. Cutover is a credential swap. After that we watch failed notifications, the sweep’s findings and the licence statistics, and retest on each Acumatica release.