HubSpot + Expandable ERP integration

Expandable ERP is built for manufacturers who have to prove what they shipped: medical device makers, diagnostic instrument builders and electronics firms that live on serial number tracking, lot control, audit trails and return authorizations. Expandable Software is backed by Mirador Software Group, a family-owned group of midmarket ERP companies, and the product runs on Microsoft SQL Server, on your own servers or in Expandable’s cloud.

Selling in these businesses is technical, and the questions a customer asks mid-cycle live in the ERP: which lot shipped, which serial numbers they hold, whether a return is still open. Finance guards the customer master. The sales team, meanwhile, runs its pipeline and its marketing in HubSpot and sees none of it.

Expandable has built this bridge once already, for Salesforce. Its packaged integration moves the customer master, sales orders, invoices and shipped serial parts into Salesforce, and inserts new Salesforce accounts into Expandable on hold. Nothing equivalent exists for HubSpot, so the work is to build the same shape against Expandable’s web services, keeping the choices Expandable made about what flows back and what never does. The on-hold insert matters most: a rep can open the relationship, and nobody can ship against an account finance has not reviewed.

Five objects mirror the packages Expandable chose for its own Salesforce integration, which is a useful signal of what its customers want in a CRM. The customer master becomes HubSpot companies and customer contacts become contacts. Sales orders, AR invoices and shipped serial numbers land on custom objects associated to the company, and service tickets can associate to a serial.

Only one thing moves back. A won deal whose company is not yet an Expandable customer creates one through the customer create call, and it goes in on hold, as Expandable’s Salesforce integration does, so finance releases it rather than discovering it. Orders stay in Expandable, where pricing and credit checks at order entry and shipment happen.

Keys are Expandable identifiers held in custom HubSpot properties. Serials key on the serial number with its part number, which costs nothing if serials are unique across parts and prevents a silent merge if they are not.

The runtime is a polling service over Expandable’s web services. They are RESTful, exchange JSON and run under Microsoft IIS beside the Expandable installation. Every data call, a query included, is an HTTP POST, and filters use Expandable’s Query by Example operators such as IN, BETWEEN and the usual comparisons. The service passes Expandable credentials to the Auth Token call and carries the token it returns.

For change detection, the documentation offers one clear source: the optional Audit Log module, which records inserts, updates and deletes on the tables you select, with the key fields, the operator and the time, in a history table. Where it is licensed, the service reads that table from its last checkpoint and queries only the records that changed, deletions included. Where it is not, the service compares full key sets per object on a nightly run. Writes into HubSpot are batch upserts on the Expandable key, followed by a separate association pass.

The deciding question is licensing. The web services need Expandable 9.3.0 or later with the web service feature key licensed; with them, a custom API integration reads every object above and can insert customers through Expandable’s own business logic. Without them, Expandable’s statement that it runs on Microsoft SQL Server makes a managed sync over read-only views the fallback: one way, no inserts, and no service to host. Where the Audit Log module is licensed too, the custom route also learns about deletions, which a view over current rows cannot show.

An iPaaS is the weakest fit. It would call the same web services one record at a time, manage the session token on every run and bill per task on every order line.

1. Scope. We confirm the Expandable release, the web service feature key, the Audit Log licence and who in finance releases customers from hold.
2. Architect. We fix the keys, the query filters, the audited tables and the single write path for new customers.
3. Build. The service is written against the SDK installed on your server, with its test utilities, and a HubSpot sandbox behind a portal allowlist.
4. Validate. We reconcile counts per object and compare open order and invoice totals with an Expandable report before cutover.
5. Operate. We watch each run against its checkpoint, keep a replay window, and retest after every Expandable release.