HubSpot + Hightouch integration

The request usually comes from a data team that has already done the hard part. Accounts, usage, plans and revenue sit in a warehouse as clean, modelled tables, and the sales team still works from a HubSpot record that knows none of it. Hightouch closes that gap without a service to run: it reads a model, works out which rows changed since the last run, and writes those rows into HubSpot.

The ask is rarely all the data. It is a health score on the company record, a plan tier a workflow can branch on, a product event on the contact timeline, or a list of accounts whose usage dropped this week. Each of those is a model the data team already trusts and a HubSpot property somebody in revenue already wants.

Hightouch now sells itself as a marketing platform and a composable customer data platform, with a free Basic Reverse ETL tier, and reverse ETL is the part a HubSpot sync uses. Its about page describes a venture-backed company with no parent named. That matters when you compare it with Census, which Fivetran now owns.

The decision worth making first is which fields the warehouse owns. A property Hightouch writes on every run should be read-only for people in HubSpot, because the next run puts the warehouse’s value back. A property people edit belongs outside the mapping.

Hightouch writes three kinds of thing into HubSpot: records on standard or custom objects, custom behavioural events on the contact timeline, and contact list membership. Records take upsert, update or insert modes, events take insert, and lists take add and remove.

The match key is the decision that lasts. Hightouch suggests matching on what HubSpot deduplicates on: email for contacts, domain for companies, or the HubSpot record ID. Email is right for contacts, because HubSpot refuses a second contact with an email already in use. Domain is weaker for companies. Two warehouse accounts can share one, and it changes when a business rebrands. We create a unique custom property holding the warehouse account key and match on that, and we do the same for deals and custom objects.

Events are the other stream worth planning. Each one needs a truly unique key in the model, or a replayed row arrives twice, and events need Hightouch connected with enterprise scopes. A custom object has to exist in HubSpot before Hightouch can sync to it.

A Hightouch sync is polling on a snapshot rather than on a timestamp. On each scheduled run Hightouch queries the model, compares the result with the previous run’s snapshot by primary key, and sends only the rows that were added or changed, along with any rows that failed last time.

Where that comparison runs is a choice. The basic engine keeps the snapshot on Hightouch’s own infrastructure and needs only read access. The Lightning engine keeps it in a schema inside your warehouse, needs write access, and is what Hightouch recommends above 100 thousand rows.

Order matters for associations. The sync for the associated object has to run before the sync that points at it, so we chain them in a sequence and set each member to a manual schedule. Replay is a full resync, which treats every current row as new. A sync idle for more than 30 days needs a reset or a full resync, because its snapshot has expired.

Three questions decide the route here. Does the warehouse already hold keyed, modelled tables? If it does, Hightouch reads them as they are, and if it does not, that modelling comes first whichever tool you pick. Is HubSpot the only place the data goes? Hightouch lists more than 300 destinations, so the same models can feed advertising and customer success tools as well. And does anything have to happen per record, such as a rule that routes a deal, a write back into an operational system, or a reaction within seconds? Then the logic needs somewhere to run, and a keyed service is that place.

Census is the like-for-like alternative. Where the warehouse is Snowflake, compare HubSpot’s own options on the Snowflake page. Where the operational data already lives in a lakehouse, see Microsoft Fabric.

1. Scope. We list the models the warehouse already holds, the HubSpot property each column lands in, and the owner of every field.
2. Architect. We create unique custom properties for the match keys, choose the sync engine, and order the syncs into a sequence with parents first.
3. Build. Models, syncs and field mappings in the client’s Hightouch workspace, with delete behaviour set per object and alerts routed to the delivery channel.
4. Validate. A full run into a HubSpot sandbox portal, with counts compared object by object and every rejected row read.
5. Operate. We review alerts and run history each week, and re-map when a warehouse model changes.