HubSpot + E21 ERP integration

E21 ERP sells itself on doing without add-ons. Its CRM is part of the ERP, and E21’s own CRM page argues that one central database removes the back-and-forth synchronization two systems need. A manufacturer or distributor on E21 that also runs HubSpot has chosen it for reasons of its own. It has also taken on exactly the synchronization E21 set out to avoid. The product is also known as Enterprise 21, the name E21’s own FAQ still uses, and the vendor’s older TGI web address now forwards to the E21 site.

The people working in HubSpot want what E21 already knows. They want to see which accounts are ordering less and which have open quotes. They want the contacts at each location, and whether an account is overdue before a rep books a visit. E21 can already alert its own users when a customer’s order pattern changes. The sellers and marketers who should act on that signal are the ones who never open E21.

Access shapes the project more than the object list does. E21 can run self-hosted, on E21’s hosting services or with another hosting provider, and its site documents no API for outside developers. What it does document is the platform. E21 runs on any ODBC-compliant database, a self-hosted install typically uses Microsoft SQL Server or Oracle, and every licence includes the complete application source code. That makes the database the route, and whoever controls it the first person to talk to.

Five objects cover the requests. E21 customers become HubSpot companies, their contacts become contacts, sales orders become deals, invoices land on a custom object and products become HubSpot products. Everything moves one way, into HubSpot, and nothing is written back to the E21 database.

Keys are E21’s own record identifiers, held in custom HubSpot properties and never matched on a name. E21 does not publish its schema, so the exact tables and columns come from the source code or from E21’s developers during discovery. Each one is confirmed against records the business already knows.

Opportunities are left out on purpose. E21’s CRM lets one opportunity link to several accounts, and running two pipelines means reconciling them forever. Where the business moves its pipeline to HubSpot, E21’s opportunities load once, with a primary company chosen for each, and new ones start in HubSpot. Where E21 keeps the pipeline, HubSpot carries orders and history beside it.

The runtime is a scheduled read, because E21 documents no webhooks or events for an outside system. A service connects to the E21 database with a read-only login, either directly or through a small agent inside the network, and reads each object on its own schedule.

Where a table carries a trustworthy modification date, the read uses it as a watermark. Where it does not, the service hashes each row and compares it with the hash it last sent, so only real changes reach HubSpot. Watermarks and hashes live in the service’s own store, never in the E21 database.

Writes into HubSpot are batch upserts keyed on the E21 identifiers, followed by a separate association pass for contacts, orders and invoices. A replay endpoint re-reads one object for a time range. A reconciliation endpoint compares counts on both sides after every run, so a gap shows up as a number rather than a complaint.

What decides the route is who can open the database, since E21 publishes no API to call instead. On a self-hosted install that is your own IT team. The choice there is between a service we build and a managed sync on Skyvia, which reads SQL Server or Oracle through an on-premises agent once the tables are agreed. On a hosted install it is the host, and the conversation starts there.

One route sits outside these cards. E21’s services group develops interfaces to third-party applications as customization work, and its Klaviyo and Mailchimp integrations show the shape that takes: rules inside E21 that push contacts out. That keeps the whole connection inside E21’s support, with E21’s roadmap rather than yours deciding what it carries next.

1. Scope. The first call includes whoever hosts E21. We confirm the database platform, whether a read-only login is possible, and which system owns the pipeline.
2. Architect. We map each object to its E21 tables from the source code, fix the key and the change signal per table, and write both down.
3. Build. The service reads under a read-only login, never writes to the E21 database, and upserts into a HubSpot sandbox portal behind an allowlist that fails closed.
4. Validate. A full backfill of customers and invoice history, reconciled by count and by open balance against an E21 report, then walked through with the person who owns receivables.
5. Operate. We watch each run against its checkpoint, keep the replay endpoint available, and recheck the column list after every E21 upgrade.