How to connect a legacy, ERP or undocumented-API system to HubSpot

Most HubSpot integration advice assumes the system on the other side has a modern, documented REST API with OAuth and webhooks. A lot of the systems that actually run a mid-market business do not. The ERP was specified before HubSpot existed. The finance system is a hosted instance with the API disabled. The "API" is a SOAP endpoint the vendor will not document, or a nightly file drop onto an SFTP server, or a database you are only allowed to read.

This is the wedge where native connectors, Operations Hub Data Sync and iPaaS tools (Zapier, Make, Workato) all run out of road. They need a clean API to connect to. When there is not one, you are into custom, real-code integration. This guide covers the approaches that work when there is no usable API, with examples from the ERP and accounting systems we see most: Sage, NetSuite and Microsoft Dynamics.

For the full picture of how the four integration methods compare, start with our pillar guide on how to connect anything to HubSpot. This page goes deep on the hardest case.

First, work out what you are actually dealing with

"No API" covers several quite different situations, and the right approach depends on which one you have. Diagnose before you build.

Most real ERP integrations are a blend of two or three of these. A Sage 200 on-premise install might give you a SQL database and a nightly SFTP export but nothing live. NetSuite has SuiteTalk and RESTlets but they are licence-gated and rate-limited. Dynamics has good APIs in the cloud and almost nothing usable in older on-premise builds.

Approach 1: reverse-engineer the undocumented API

When an interface exists but is undocumented, the job is to recover its contract. That means capturing real traffic between the system and its own client, inspecting the request and response shapes, and building a typed adapter around what you observe rather than what a missing spec claims.

In practice this looks like: proxying the desktop or web client to see exactly which endpoints it calls, mapping authentication (token, session cookie, signed header), confirming pagination and rate behaviour under load, and pinning down how the system represents the objects you care about, such as invoices, orders and account balances. You then wrap all of that in a single integration service so the fragility lives in one tested place, not scattered across HubSpot workflows.

The risk to manage is that an undocumented contract can change without warning on a vendor update. We handle that with schema validation on every payload and alerting that fires the moment a response stops matching the shape we reverse-engineered, so a silent break becomes a logged, actionable event.

Approach 2: middleware adapters as the translation layer

You almost never connect a legacy system directly to HubSpot. You put a middleware service in between: a small, owned application that speaks the legacy system's language on one side and clean HubSpot API calls on the other.

This adapter is where the real engineering lives. It normalises mismatched data models (a single HubSpot company might map to several legacy account codes), it holds the field mapping and transformation rules, it manages retries and idempotency so a failed sync does not create duplicates, and it gives you one log to read when something goes wrong. Crucially, it lets you swap the legacy side later, when that Sage instance is finally upgraded, without touching anything on the HubSpot side.

This is core data engineering work: modelling the data, building the pipeline, and making it observable. It is the difference between an integration that survives the first vendor update and one that quietly stops syncing two weeks after launch.

Approach 3: database, SFTP and file exchange

When there is genuinely no callable interface, you fall back to the data itself. Two patterns cover most cases.

• Direct database reads. If you have read access to the ERP's SQL database, a middleware service can query it on a schedule and push changes to HubSpot. This must run server-side inside a controlled environment, with read-only credentials wherever possible, and it should query views rather than raw tables so a database upgrade does not break you.
• SFTP and file exchange. Many finance systems will happily export a nightly CSV or XML file. A file-watcher pipeline picks up each new file, validates it against an expected schema, transforms it and upserts into HubSpot, then archives the file with an audit trail. Get the validation right: a malformed export should be quarantined and alerted, never partially loaded.

File exchange is not real-time, and you should be honest with the business about that. If the finance data only changes once a day anyway, a nightly file is fine. If sales genuinely need live balances, file exchange is the wrong tool and you should be looking at a database or API path instead. We cover that trade-off in detail in real-time two-way sync versus polling.

Approach 4: security for firewalled and on-premise systems

Legacy and ERP systems are often the most sensitive in the business and the least exposed to the internet by design. Connecting them to a cloud platform is a security decision, not just a technical one.

• Reaching a firewalled system: a site-to-site VPN, a fixed-IP relay the firewall can allowlist, or an agent that runs inside the network and makes only outbound calls so no inbound ports open.
• Credentials: stored in a secrets manager, never in workflow steps or code; read-only where the use case allows; rotated on a schedule.
• Least privilege: the integration user should see only the objects it needs. An invoice sync does not need write access to the general ledger.
• Auditability: every sync logged, every failure alerted, every field mapping documented, so a finance or security review can see exactly what moves and why.

This is the part no-code tools cannot give you. You cannot put a VPN or an on-premise agent behind a Zapier zap, and you should not be pasting ERP database credentials into a third-party iPaaS UI.

Where your specific ERP or accounting system fits

The approach changes by system and by version. Rather than duplicate per-app detail here, we keep a profile for each common integration in the Integration Library, with the realistic method, the sync constraints and an indicative cost band. If you run one of these, see your app:

• Browse the Integration Library for Sage, NetSuite, Dynamics and 40+ other systems

One important distinction: this guide is about an ongoing two-way sync between systems that both stay in use. If you are switching CRM entirely and moving the data once, that is a different job covered by our data migration service. And if your end goal is a customer portal, remember the portal is only as good as the live data behind it, which is exactly why the integration layer matters.

The honest summary

There is almost always a way to connect a legacy, ERP or proprietary system to HubSpot, even when the vendor swears there is no API. It just stops being a configuration job and becomes an engineering one: reverse-engineer what exists, put a middleware adapter in the middle, fall back to database or file exchange where you must, and treat security as a first-class requirement throughout. That is the work, and it is the work that holds up over time.

SpotDev is a HubSpot Diamond partner and Custom Integration Accredited, with integrations delivered across 300+ projects, including the awkward legacy and ERP cases. If you have a system that everyone else has called impossible, talk to us about a custom HubSpot integration.