Enriching leads in Clay is only half the job — the data has to land in your CRM cleanly, or you've just built a very expensive way to create duplicate contacts. This is where most Clay-to-HubSpot setups go wrong: they push enriched rows back with the wrong action, no dedup key, and blank-value overwrites turned on, and within a week the CRM is dirtier than before. This guide walks through the native Clay ↔ HubSpot integration the way a GTM engineer actually runs it — the import → enrich → write-back workflow, the dedup and field-mapping rules that keep it clean, and how to automate it.
The integration mechanics, actions, and dedup behavior below are drawn from Clay's and HubSpot's official documentation. Clay's exact plan names, per-write credit costs, and which tier gates native auto-sync are from secondary pricing sources and are flagged directional — confirm them on Clay's live pricing page before budgeting.
Import a filtered HubSpot list into a Clay table (not your whole portal), keep the HubSpot Record ID on every row, enrich, gate writes so only verified data goes back, then Update keyed on the Record ID with "Ignore blank values" on. Reserve Create for genuinely net-new records. Do that and you get clean, enriched CRM data with zero duplicates and no clobbered fields. Everything else in this guide is detail on top of those two rules. If you're new to Clay itself, start with the Clay workflow playbook and waterfall enrichment setup first.
Clay's HubSpot integration lets you import, create, update, and manage HubSpot objects directly from a Clay table. It supports contacts, companies, leads, deals, and custom objects. There are two families of actions:
| # | Step | Action / setting | Why |
|---|---|---|---|
| 1 | Connect HubSpot | OAuth with minimal scopes | Least-privilege, auditable |
| 2 | Import a filtered list | Source/Lookup action, filtered to a HubSpot view | Control cost; avoid stale full-portal syncs |
| 3 | Carry the Record ID | Include the HubSpot Record ID column | This is your dedup key for write-back |
| 4 | Enable Auto-update | ~24h refresh cadence | Keeps Clay rows current with HubSpot |
| 5 | Enrich & score | Waterfall + formula columns; keep originals | Compare enriched vs existing values |
| 6 | Gate the writes | "Only run if" (e.g., email verified) | No junk data into the CRM |
| 7 | Write back | Update keyed on Record ID + Ignore blank values ON | No dupes, no overwrites |
| 8 | Test small | Run 5–10 rows, verify in HubSpot | Catch mapping errors before scale |
| 9 | Scale & automate | Re-enable auto-update / add a HubSpot webhook trigger | Ongoing, hands-off enrichment |
Duplicates are the number-one failure mode, and they're entirely avoidable. The mechanics:
"Match before write" is the whole game. This is the same hygiene discipline covered in our CRM data hygiene guide — enrichment that creates duplicates is negative value.
Not every field should be written the same way. The difference between a clean sync and a corrupted CRM is per-field write rules:
| Clay column | HubSpot property | Write rule |
|---|---|---|
| HubSpot Record ID | (object ID) | Dedup key — match/Update target, never overwritten |
| Verified email | Only if verified; email is HubSpot's contact dedup key | |
| Company domain | domain (company) | Match key for companies; only-if-empty |
| Job title | jobtitle | Only-if-empty (don't clobber rep-entered) |
| LinkedIn URL | linkedin_url (custom) | Always (safe to refresh) |
| Employee count | numberofemployees | Only-if-newer / only-if-empty |
| Clay enrichment status | clay_enriched_at (custom) | Always (audit stamp) |
| Lifecycle stage | lifecyclestage | Do not write from Clay (owned by CRM/marketing ops) |
| Contact owner | hubspot_owner_id | Do not write (never overwrite ownership) |
Two settings make this safe: "Ignore blank values" on every write (so an empty enrichment never wipes a good field), and Clay's "Only run if" conditional logic to enforce only-if-empty / only-if-newer / only-if-verified rules. Writing enriched data into a dedicated property set keeps changes auditable and sensitive fields untouched. (only-if-empty and only-if-newer patterns are documented by Clay; the dedicated-property-set convention is directional best practice.)
Beyond scheduled auto-update, you can make enrichment event-driven:
Writing to HubSpot isn't free of Clay's economy: writes are Actions (Clay separates Data Credits for buying third-party data from Actions for orchestration and sending data to integrations). Each action costs a small fraction of a cent, and Clay says most customers never hit their Actions ceiling. (directional) On plan gating: the base HubSpot integration requires Clay's Pro plan or higher (verified in Clay's docs), while native CRM auto-sync, HTTP API access, and webhooks are reported to sit on the Growth tier and above. (directional — plan names, prices, and credit counts vary; confirm on Clay's live pricing page.) For the full breakdown, see our honest Clay pricing review.
Clay's native actions cover most CRM-sync needs. When you need conditional routing, custom dedup logic, or fan-out to several tools at once, route Clay's HTTP API column to an n8n (or Make) webhook, do the logic there, and let n8n write to the CRM — n8n can also push new leads and signals back into a Clay table. That's a deeper pattern covered in our Clay + n8n integration guide. For choosing the CRM itself, see best CRM for B2B outbound.
Not a live bidirectional sync. Clay imports HubSpot records with a scheduled auto-update (around every 24 hours) and pushes data back through explicit Create, Update, and Create-association actions. It's an import-plus-write-actions system you compose, not a single always-on sync toggle — changes flow on Clay's refresh cadence and when your write actions run, not instantly.
Not if you use the Update action keyed on the HubSpot Record ID, or Lookup-then-Update on email/domain when you don't have the ID. Reserve Create for records that genuinely don't exist. HubSpot also auto-deduplicates contacts by email and companies by domain as a backstop, but you shouldn't rely on that alone — the Record-ID Update path is what actually prevents duplicates.
The HubSpot Record ID is the best dedup key because it targets an exact existing object for an Update. Email is HubSpot's native dedup key for contacts, and domain is the key for companies — use those to look up and resolve a Record ID when a row doesn't already carry one.
Yes. Writes to HubSpot count as Clay Actions (distinct from the Data Credits you spend buying third-party data), each costing a small fraction of a cent. Native CRM auto-sync, HTTP API access, and webhooks are reported to require Clay's higher tiers — confirm the current plan gating and prices on Clay's live pricing page.
Yes. Set up a contact-based HubSpot workflow that fires a webhook (email, company domain, Record ID) to Clay when a contact is created; Clay enriches the record and writes the values back. The newly written property can then trigger further HubSpot workflows, such as enrolling the contact in a sequence or setting a lifecycle stage.
Turn on "Ignore blank values" on every write so failed enrichments can't wipe existing fields, use Clay's "only run if" conditional rules (only-if-empty, only-if-newer, only-if-verified), never write owner or lifecycle-stage fields from Clay, and write enriched data into a dedicated set of custom properties so changes stay auditable.
Want Clay-enriched data flowing into HubSpot without the duplicate mess? GenFlows builds the Clay → CRM plumbing — dedup keys, conditional write rules, and event-driven enrichment — so your pipeline stays clean and enriched. Start with the Clay playbook or talk to our team.
By the GenFlows GTM engineering team. Integration mechanics, actions, and dedup behavior are from Clay and HubSpot documentation; Clay's plan names, per-write credit costs, and the exact tier gating native auto-sync are from secondary pricing sources and are directional — confirm on Clay's live pricing page. Last updated July 2026.