HubSpot + ECI integration

ECI Software Solutions sells a family of manufacturing ERPs rather than one, so a HubSpot project starts by naming the member on site. M1 serves discrete manufacturers, JobBOSS² serves job and machine shops, and Deacom serves batch and process manufacturers. ECI still supports Macola and E2 MFG for existing customers, and each of those has a page of its own here.

Each product carries some sales tooling. M1 builds CRM features into the ERP, and JobBOSS² offers CRM as an add-on module. A business that already runs marketing and sales in HubSpot ends up with two customer lists, and sellers who cannot see a quote’s status, an order’s progress or an unpaid invoice without asking the office. In a job shop the quote carries most of the sale, and ECI’s own manufacturing page promises job shops quotes, revisions and production tracked in one system. That quote is the record a seller wants beside the HubSpot deal.

What sets ECI apart in this tier is how much of the route is written down. ECI publishes OpenAPI references for a product-agnostic ERP API that reads M1, JobBOSS², Deacom and Macola, plus product APIs for hosted JobBOSS² and M1. The catch sits outside the code. ECI activates every API per customer, and coverage differs by product, so discovery confirms both before anyone writes a line of the service.

Six objects carry the value. ECI’s organizations become HubSpot companies and their contacts become HubSpot contacts. Quotes become deals. Sales orders and AR invoices land on custom objects associated to the company, and parts become products.

Coverage is the part to check per product. Through the ERP API, M1 supports every one of those objects. JobBOSS² supports all of them except AR invoices, which its own API carries instead. Deacom supports sales orders and parts but lists no organization, contact or quote resource, so a Deacom project needs a customer route agreed in discovery.

Everything moves one way on a first build, because each ERP owns the customer, the price and the order. Keys come from the API rather than from names. Every resource carries a uniqueID, a GUID in M1 and an integer in JobBOSS², and ECI guarantees it only within one resource and one company account. We store it in a custom HubSpot property together with the product and company it came from, so two sources can never collide.

ECI’s published references describe no webhook or event subscription, so the service polls each resource on a schedule from a stored watermark. It authenticates with OAuth 2.0 client credentials issued in ECI’s Integration Engine Management Console, caches each token for its 60 minute life, and fetches a fresh one before expiry, because there is no refresh token.

The watermark is the rowVersion field, which ECI documents as rising on every insert and update. Each read asks for rows above the last value seen, sorted by rowVersion and paged with take and skip. For JobBOSS² invoices, read through the JobBOSS² API, the lastModDate field plays the same part. The highest value per resource is saved only after HubSpot accepts the batch.

Each batch lands in HubSpot as an upsert keyed on the stored uniqueID, and a separate association pass follows. For reconciliation, the ERP API’s count parameter returns a total without the rows, and we compare it with HubSpot per resource after every cycle.

The product and its hosting decide most of this. A custom API integration over the ERP API is our default for M1 and JobBOSS², because ECI documents the resources, the watermark and the paging, and one service can then serve either product. Hosted JobBOSS² and M1 customers also get a product API with write operations, which matters once HubSpot needs to create records.

The Commercient apps in the marketplace are the alternative for a standard mapping, one named for M1 and one for JobBOSS², run on Commercient’s side. We steer away from general automation platforms here, because ECI’s token flow and rowVersion paging would need hand-built HTTP steps. That is a custom build with a per-task bill on top.

1. Scope. We confirm the ECI product, its hosting, which APIs ECI has activated and which databases exist, then list the objects sellers need.
2. Architect. We fix the resources per product, the uniqueID keys with their source, the rowVersion watermarks and any write back, in writing.
3. Build. The service is written against a test database where one exists, with its own API user and a HubSpot portal allowlist that fails closed.
4. Validate. We run a full load into a HubSpot sandbox and reconcile totals per resource with the API’s count-only queries.
5. Operate. Cutover swaps the API user. We watch the run history, keep replay available and recheck coverage when ECI publishes a new API version.