HubSpot + Epicor integration

Epicor is three ERPs under one name, and the first hour of any HubSpot project goes on finding out which one is in the building. Kinetic runs discrete and make-to-order manufacturers. Prophet 21 runs wholesale distributors, and Eclipse runs electrical, plumbing, HVAC and PVF distributors. They share a vendor, not a data model or an API, so a connector written for one reads nothing in the other two.

Each of them already carries some CRM of its own. Kinetic has lead and opportunity management and a mobile CRM app, Prophet 21 has contact management and quote tracking, and the CRM integration Epicor offers for Kinetic is to Salesforce. A business that runs marketing and sales in HubSpot ends up with the facts sellers need sitting in an ERP they never open: open quotes, orders on the way, invoices past due.

In practice the ask is narrow. Put open quotes on the company record so a seller can chase them. Flag an account with overdue invoices before somebody books a renewal call. Show a service rep what the customer bought last. Each of those is one object moving one way, and the Epicor product in front of us decides which API carries it. Settling that list first keeps the build to the records people will actually look at.

Six objects cover what sellers ask for. The Epicor customer becomes a HubSpot company and its contacts become HubSpot contacts. Quotes become deals, because a quote is won or lost once and a deal already has that shape. Sales orders and invoices land on custom objects associated to the deal and the company, and parts become products, which Prophet 21 calls items.

Everything moves one way to begin with. Epicor owns the customer, the price and the order, and finance is right to be wary of a sales tool editing any of them. The write back worth planning is a won deal creating a customer, and we hold that for a second phase behind a review step.

Keys need one extra part. Kinetic works with multiple companies in one system and Prophet 21 lists multicompany management, so every key carries the Epicor company as well as the record’s own number, held in a custom HubSpot property. A key without the company is only safe until the second company goes live. Names never serve as keys, because they are the field people edit most.

Neither Kinetic nor Prophet 21 documents a webhook subscription on its public pages, so the runtime polls: a service reads each object on a schedule, starting from a stored watermark. For Kinetic, it calls the OData REST services, or a BAQ built for the integration, with an API key whose access scope names exactly the services it needs, alongside a dedicated Epicor user. For Prophet 21, it reads through the Data Services API, which Epicor describes as secure OData reads from the Prophet 21 database.

Each object keeps its own checkpoint in the service, per Epicor company, so a restart resumes where it stopped. HubSpot receives batch upserts keyed on company and number, followed by a separate association pass that links quotes to companies and orders to the deals their quotes opened. Running either step twice changes nothing.

A reconciliation job counts records per company and object on both sides after each cycle and reports the difference instead of hiding it. A replay endpoint re-reads any object for a chosen window.

Three things decide the route on an Epicor project: which of the three ERPs you run, whether you already pay for Automation Studio, and how far past the customer record the sync has to reach.

A custom API integration is our default because it treats Kinetic and Prophet 21 the same way at runtime and carries quotes, orders and invoices on keys that survive a replay. Automation Studio is Epicor’s own iPaaS, powered by Workato, with Epicor-built connectors for all three ERPs. We start an Eclipse project there, because we have not found a public API reference for Eclipse. The Commercient apps in the marketplace are the third route, a packaged sync that Commercient runs and supports.

1. Scope. We confirm which Epicor product and release you run, where it is hosted, how many companies it holds and which objects sellers need.
2. Architect. We fix the objects, the company-scoped keys, the checkpoint per object and the API key’s access scope, and write them down.
3. Build. The service is built against Kinetic’s Pilot environment, or a test copy of Prophet 21, with a HubSpot portal allowlist that fails closed.
4. Validate. We reload each object into a HubSpot sandbox and reconcile counts per company with the person who owns the ERP.
5. Operate. Cutover swaps the Pilot key for the production one. We watch the run history, keep replay available, and retest in Pilot before each upgrade.