HubSpot + Census integration

Most teams asking about Census already run it, or already run Fivetran. Census built its name on reverse ETL, sending warehouse data into business tools, and Fivetran agreed to acquire it in 2025. It now sits inside the Fivetran account as Fivetran Activations: the Census website redirects to Fivetran, and the Census documentation lives in Fivetran’s Activations docs.

For a HubSpot team that changes one thing. A company already loading HubSpot, billing and product data into a warehouse with Fivetran connectors can send the modelled results back out under the same account, the same access controls and the same usage-based bill. The HubSpot App Marketplace listing still carries the Census name.

What revenue teams ask for is the same as with any reverse ETL tool: a plan tier and usage figures on the company record, a lead score built from product behaviour, subscription preferences kept in step with a consent table. What differs with Census is how the sync key is chosen, and how much that choice costs in speed.

Existing Census customers keep an annual plan until its term ends, then move to Fivetran’s pricing. Month-to-month Census plans have already ended, and an account whose plan runs out before a Fivetran plan is chosen may be frozen until one is. That is worth checking before any new sync is built.

Census writes to more HubSpot objects than most teams use: companies, contacts, deals, leads, line items, products, custom objects, appointments, tickets, static list membership, subscription preferences and custom behavioural events. Behaviours vary by object. Contacts take create only, update only, update or create, mirror and delete. Companies take update only, update or create, and mirror. Tickets can only be sent.

The sync key is where the design lives. HubSpot object IDs and contact emails are fast, and any other key is slow. A custom property is only usable as a key when it is single-line text or a number. We key companies and deals on a unique custom property holding the warehouse identifier. HubSpot only lets the unique rule be set when a property is created, so we create it right the first time.

Custom objects need one more step. The key property has to be added to the object’s searchable properties through HubSpot’s API before Census can match on it, and the setting in HubSpot’s own screens is a different thing.

Census runs as an incremental sync from a warehouse source into HubSpot. Each activation sync names a source table, dataset or segment, a HubSpot object, a behaviour, a sync key and a field mapping. On each run it sends only records that are new or changed since the last run.

State lives in one of two places. The basic sync engine keeps it on Fivetran’s side and needs only read access to the warehouse. The advanced engine keeps it in a bookkeeping schema inside the warehouse, needs write access to that schema only, and runs faster. Mirror syncs compare against what they have already sent, so the first run is an upsert of everything.

Runs start on a schedule or a cron expression, through the API, or after a dbt Cloud job. The sync history separates invalid rows, which Census held back for a null or duplicate key, from rejected rows, which HubSpot refused, with a sample of up to 100 of each. We read both after every run.

The choice here is less about the tool than about the account it lives in. A business already paying for Fivetran connectors adds activations to the same bill, measured in monthly active rows counted once per sync key. A business with no Fivetran footprint should compare it with Hightouch, which bills its self-serve tier by active syncs rather than rows. Either way the sync stays a mapping and a schedule. A rule that decides per record, a write back into an operational system, or a change that must land within seconds needs a service that holds the logic. For how the data reaches the warehouse in the first place, see Fivetran.

1. Scope. We list the warehouse tables or datasets, the HubSpot object and behaviour for each, and who owns every mapped field.
2. Architect. We choose the sync engine, create unique text or number properties for the keys, and register custom object keys as searchable.
3. Build. Activation syncs in the client’s Fivetran account, with null handling set per field and mirror used only where archiving is intended.
4. Validate. A full run into a HubSpot sandbox portal, reading the invalid and rejected samples until both are empty.
5. Operate. We watch the sync history and the monthly active rows, and re-key a slow sync before it becomes a late one.