HubSpot + E2 Shop System integration

E2 Shop System is the job shop ERP Shoptech built, and it passed to ECI Software Solutions when ECI bought Shoptech in 2020. It runs on a Windows server the shop keeps itself. ECI now sells JobBOSS² in its place, describing it as formerly E2 Shop, and supports E2 MFG, the edition for repetitive production, for existing customers only. The shops still on E2 know exactly where their quotes live, and it is not where their sellers work.

Estimators build quotes in E2’s Office application, and the office enters orders, purchasing and accounting there too. Sellers running their pipeline in HubSpot cannot see which quotes are open, which became orders or what a customer still owes. Shoptech’s own requirements have remote users reach E2 through Remote Desktop, so handing every seller an E2 seat is rarely the answer.

The investment question comes first. ECI’s successor to E2 Shop is JobBOSS², so an integration to E2 should be cheap to build and cheap to switch off. That points to a managed sync reading the database, with no service of our own to host or patch, rather than a custom build that would outlive the ERP it reads. When the shop moves, the sync is retired and HubSpot keeps the history it collected along the way.

Four objects carry the useful facts. E2 customers become HubSpot companies. Quotes become deals, since the quote is where a job shop’s sale starts and it is won or lost once. Orders land on a custom object associated to the company, and so do invoices where the shop raises them in E2. Some shops run E2 beside QuickBooks, and then the invoice row comes from there.

Data flows one way, out of E2, which remains the system of record. Without a published API the only programmatic write path would be its database, which we do not touch. A won deal still becomes an order the way it always has: somebody enters it in E2.

Keys come from the codes E2 users already work with: the customer code and the quote, order and invoice numbers, each scoped by the company database. Shoptech’s setup creates one SQL Server database per company, so a shop with two companies has two sets of numbers that can overlap. E2’s table layout is not publicly documented, so we map the tables against the shop’s own database during discovery.

The shape is a managed sync over SQL. The Skyvia Agent runs on a machine inside the shop’s network that can reach the E2 SQL Server, and it talks to Skyvia in encrypted form without a dedicated external IP or an open port. Skyvia’s packages read E2 through a read-only SQL login of their own and load HubSpot in a fixed order: customers first, then quotes, orders and invoices, so every parent exists before its children.

The packages run after hours and upsert on the E2 codes held in custom HubSpot properties, so a rerun updates rather than duplicates. Tables that carry a modification date load incrementally, and the rest reload in full on a schedule we size in discovery. Skyvia keeps the run history. A failed package stops the chain and alerts us rather than loading children without their parents.

On E2 the choice is short. There is no marketplace app, and ECI’s published integration APIs cover M1, JobBOSS², Deacom and Macola but not E2, so the database is the route. The only question is who runs the reads.

A managed sync on Skyvia is our recommendation because it needs no service of our own, costs little to build and costs nothing to retire when the shop moves to JobBOSS². A custom integration, meaning a service of ours reading the same database, earns its place only when quotes must reach HubSpot within minutes or the mapping needs logic a package cannot hold. Shops still on an Access database start with Shoptech’s documented upgrade to SQL Server, or fall back to a scheduled export.

1. Scope. We confirm the E2 edition and version, SQL Server or Access, how many company databases exist, and where invoices are raised.
2. Architect. We map E2’s tables against the shop’s database, fix the codes used as keys and set the order the packages run in.
3. Build. The packages are built against a restored copy of the database where the shop can provide one, loading a HubSpot sandbox first.
4. Validate. We reconcile counts per table against E2 and walk the open quotes with the estimator who owns them.
5. Operate. We watch each run, recheck the mapping after every E2 update, and retire the sync cleanly when the shop moves to JobBOSS².