Handling 100M+ HubSpot syncs / month across 20+ ERPs
How we built an integration platform that reaches cloud ERPs, on-premise ERPs and ERP databases with no inbound path at all — from a single codebase.
Selling HubSpot-to-ERP integration usually means building each one as a separate product: new code, new authentication, new infrastructure, six months to the first customer.
Ten ERPs is ten products to maintain, and every one of them ages independently.
The brief was a platform instead — one system that could take on a new ERP without becoming a new product.
Two things stood in the way:
Step 1: ERPs aren't all reachable the same way
Most integrators only serve the easy case.
Cloud ERPs are straightforward: direct HTTPS to a documented API.
On-premise ERPs that expose an API usually sit behind a firewall that admits known addresses only. Those run through a static-IP gateway, so the customer allowlists one address rather than opening a range.
And then there are ERP databases with no API and no inbound path at all. Here the platform doesn't get in. An agent runs inside the customer's own network, opens the connection outward, pulls signed configuration and pushes data back. Database credentials never leave the premises, and the customer's firewall keeps every inbound port shut.
That third path is the one that answers "our system has no API and IT won't open anything".
Step 2: Every new ERP risks being a new product
Each ERP is described by an adapter: schemas, field mappings, properties, object relationships, and what that ERP is and isn't capable of.
Everything else — scheduling, transport, authentication, telemetry, the interface, billing — is shared and untouched.
Authentication in particular is normalized upstream. Four different schemes resolve into a single credential model, with token refresh and expiry handled centrally rather than per integration.
The practical effect is that a new ERP integration is measured in weeks rather than months, and twenty of them remain one codebase to maintain rather than twenty.
ERPs reachable three different ways
Cloud, on-premise behind a firewall, and databases with no inbound path at all.
Four authentication schemes, one model
OAuth 2.0, machine-to-machine credentials, basic auth and API keys, resolved before anything downstream sees them.
Volume that grows with every account
Source databases exceeding fifty million records at peak, on shared infrastructure, across tenants with nothing in common.
Adding an ERP is configuration, not a new product.
More than a hundred million sync events a month, across dozens of customer accounts and 20+ ERPs, on one shared platform. Source databases that exceed fifty million records at peak, with every change at source propagating through.
A new ERP takes weeks rather than months, so the commercial decision to support one stops being a six-month bet.
The addressable market includes the systems nobody else reaches — the on-premise databases that have no API and no way in.
And a fix to scheduling, authentication or telemetry lands once, for every ERP integration at the same time, instead of being ported across a dozen products.
Data problems shaped like this one?
If some of this reads like your situation, say which part. Datsugi replies within 2 business hours, guaranteed (CET).
Arrigo Lupori
Founder & Managing Director