HubSpot + Fivetran integration

Fivetran usually arrives from the analytics side. Someone needs pipeline, campaigns and support tickets in the same warehouse as billing, product usage and finance, and HubSpot’s own reports cannot join to any of those. Fivetran’s HubSpot connector copies the portal into the warehouse on a schedule, table by table, so analysts query HubSpot with SQL beside everything else.

That makes Fivetran the first half of a round trip rather than a sync into HubSpot. Data leaves HubSpot, gets modelled in the warehouse, and the useful results come back through a separate product. Fivetran now owns both halves. It acquired Census, which it sells as Fivetran Activations, and it completed a merger with dbt Labs in 2026, so the loader, the modelling layer and the return trip can sit with one vendor.

What a revenue team gets from this is indirect but real. Deal stage history lands as rows with start and end times, so time in stage becomes a query. Engagements and email events land beside the CRM objects, and property history shows how each value changed over time. A churn model or a pipeline forecast built on those tables is only as good as the copy underneath it.

The question worth settling first is which tables you need. The connector can copy most of HubSpot, and every row it processes in a month is billed, so a connection that copies everything by default costs more than one scoped to the reports.

Fivetran lands HubSpot’s own schema rather than a mapping you design. Each object becomes a table: contacts, companies, deals, tickets, line items, products, leads, orders, custom objects and more, with association tables between them and pipeline tables for their stages. Engagements land as notes, emails, tasks, meetings and calls, each only if its table is selected.

Keys are HubSpot’s record IDs, which is the right choice in this direction because HubSpot owns every record. Merges are the subtle part. A merged contact keeps its absorbed IDs in a merged IDs column, a merged deal gets a row in a separate merged deal table, and a merged company is marked deleted.

History mode adds a property history table beside each current-state table, and deal stages get their own table with an entry and exit time per stage. A history table only syncs when its current-state table does, and it cannot be switched between modes, because Fivetran reads history straight from the API.

Fivetran hosts the connector, so there is nothing to deploy. It authorizes through the Fivetran app in HubSpot, or through a private app’s access token, and reads incrementally on a fixed interval: every six hours by default, and as often as every minute on an Enterprise or Business Critical plan.

Deletes arrive three ways, because HubSpot’s API has no single mechanism for them. Companies, contacts and deals get webhooks. Tickets, line items, products, custom objects and a few others are checked once a day. Pipelines, lists and teams are compared with their previous versions, and contact and company list memberships are re-synced every weekend.

Replay is a table-level or connection-level re-sync, and re-syncing a parent table re-syncs its children. In house terms this is polling on a watermark run by the vendor: Fivetran keeps the state, and the warehouse holds the result.

Start with the warehouse. If it is Snowflake and the portal has Data Hub Enterprise, HubSpot’s own Snowflake Data Share puts CRM data in the warehouse with no pipeline at all. For any other warehouse or tier, Fivetran is the packaged route, and its bill follows the rows it moves. A small service reading HubSpot’s CRM API on a modified-date watermark makes sense when three or four objects are all the reports need and a fixed running cost matters more than breadth.

The return trip is a separate decision. Fivetran’s own answer is Activations, covered on the Census page, and Hightouch reads the same tables. Where a lakehouse already holds the operational data, Microsoft Fabric is worth a look, and Fivetran can land data there too.

1. Scope. We list the reports the warehouse has to answer, then the HubSpot tables they need, and nothing more.
2. Architect. We decide history mode per object, the historical start date for event tables, and the sync frequency the plan allows.
3. Build. The connection is created in the dashboard through the Fivetran app, authorized by a Super Admin, with unused tables blocked.
4. Validate. We compare row counts per object with HubSpot and check that a test deletion and a test merge land as documented.
5. Operate. We watch monthly active rows and sync history, and run the table re-syncs that email events and custom object associations need.