How to connect HubSpot to an ERP that has no API

“Just connect it to HubSpot” stops being simple the moment the other system has no API. I’ve worked on two projects around Epicor Eclipse, which exposes none, and they ended up with completely different designs. Both started from the same question: what does each system own?

Start with ownership, not plumbing

Before choosing a tool, write down which system is the source of truth for every record and field that matters: customers, products, prices, stock on hand, orders, invoices. If two systems both think they own a value, the integration will eventually overwrite something important.

That list usually points at one of three designs.

Option 1: move the ERP’s job into HubSpot

For a luxury home fixtures retailer with two showrooms and a warehouse, the plan was to replace Eclipse rather than integrate with it. So I built the ERP on top of HubSpot:

• HubSpot became the system of record and the sales interface, with 5 custom objects (PO Line, PO Receipt, Inventory Movement, Branch and Cycle Count Line), 81 custom properties and 4 deal pipelines.
• Postgres held the pricing rules, with a resolver that was unit tested.
• n8n was the automation layer and the only process allowed to write inventory, across 11 workflows.

Two design choices did most of the work. Inventory had a single writer, because concurrent updates corrupt a stock balance. And every movement went into an append-only ledger object, so any balance can be checked against its history.

This is the right path when the old system is being retired anyway and HubSpot is where people already work. It’s the most work up front, and it only fits plans that include custom objects.

Option 2: put your own service in front of the data

For an equipment distributor on the same ERP, the goal was smaller: let sales place orders and see live inventory from the HubSpot deal record. Their portal didn’t include HubSpot’s serverless functions, so I split it in two:

• A HubSpot module as the front end, inside the deal record.
• A small Node service on the client’s own server, bound to localhost and published only through their existing TLS site, with secrets in a root-only file.

The service handled authentication, request validation and CORS, and it refused orders against closed or lost deals. An n8n workflow on HubSpot’s deal-creation webhook wrote the order page link onto every new deal. Measured live, the read path returned a full inventory payload for an open deal in roughly 1.3 seconds.

This path fits when the ERP stays and people need its data inside HubSpot without copying all of it across.

Option 3: exchange files on a schedule

If the ERP can export reports and import files, a scheduled job can move data in batches. It’s the cheapest option and the slowest: numbers are only as fresh as the last run, and you need to plan for failed or partial files. It’s a reasonable start for data that changes slowly, like a product catalogue, and a poor fit for stock levels during the sales day.

How to choose

Details that bite in every version

• HubSpot webhooks arrive in batches. One request can carry up to 100 events, so the receiving flow has to process every event, not just the first.
• Make every load safe to repeat. Key records on a stable ID so a retry updates instead of duplicating.
• Give each shared number one writer. Stock, credit limits and balances should be written by exactly one process.
• Keep an audit trail. When someone asks why a number changed, you want a record, not a guess.

If your ERP has no API and your team keeps asking for its data in HubSpot, that’s the problem I like most.

Written by Ali Ismail, who runs TechPad and builds HubSpot integrations, migrations and automation.