Clay + HubSpot: two-way CRM enrichment and sync
Two-way does not mean two databases overwriting each other. It means read, enrich, controlled write: pull records by HubSpot Object ID, enrich them in Clay, write back only the fields you decided Clay owns.
This page covers object coverage, OAuth scopes, field mapping, duplicate prevention, sync cadence and where the native connector stops.
Four things the marketplace listing will not tell you
It is not a real-time sync
It is a scheduled loop. Default is 24 hours; higher HubSpot plans allow daily or 15-minute intervals. If your routing rule needs to fire on a form submit, the native sync is the wrong mechanism.
Tasks are not a native object
Contacts, companies, deals and custom objects are covered. Tasks are not in the connector — creating them means a custom HubSpot API build on top.
There is no automatic conflict resolution
Nothing arbitrates when Clay and HubSpot disagree. You define it: ignore empty values, restrict property ownership per field, threshold on confidence. Undefined means last writer wins.
Per-connector rate limits are unspecified
Clay does not publish per-connector limits; they inherit from HubSpot's platform API limits. We will not invent a number — we measure yours against your portal's tier during the audit.
What you can actually sync between Clay and HubSpot
Native means the connector does it. Custom build means it is possible, but through the HubSpot API with orchestration around it — which is where our work starts.
How to connect Clay to HubSpot
OAuth, scoped down. The five minutes of work is the connection; the day of work is deciding which fields Clay is allowed to touch.
Authorise over OAuth
Connect from Clay's integrations panel with a HubSpot user that has the permissions you intend the integration to have — not a super admin by default.
Scope the grant
Request read and write only on the object types in play. A connection scoped to contacts cannot silently start rewriting deal amounts six months later.
Import by view or filter
Pull a HubSpot list or filtered view into a Clay table. Object ID comes along; keep that column and never overwrite it.
Declare field ownership
Write a schedule of which properties Clay owns, which are read-only, and which need a human before they change. This is the artefact that prevents the mess.
Dry-run on a held-out slice
Run the write against 50 records with logging on and writes disabled, diff the intended changes, then turn it on.
Scope names follow HubSpot's public API convention and should be confirmed against your portal's app settings at connect time. Verified 27 August 2026.
Duplicate prevention is a mapping decision, not a feature
Every write is an update-or-create decision. Match on HubSpot Object ID and it is deterministic. Match on email or company name and you are one typo away from a second record.
Object ID, always
Carry the HubSpot record ID through the whole table. It survives email changes, domain changes and merges — nothing else does.
Never write a blank
A missed enrichment returns nothing, and nothing written over a good value is data loss. Skip-if-empty on every mapped property.
One writer per property
Clay owns enrichment fields and scores. Humans and workflows own lifecycle, owner and amounts. The overlap set should be empty.
Four builds that pay for the integration
Each one is a loop, not a one-off list build: HubSpot supplies the population, Clay supplies the evidence, the write is conditional.
Fill the gaps you can name
A HubSpot view of companies missing employee count, industry or tech stack feeds a Clay table nightly. The waterfall stops at the first good answer; only the missing property is written back.
Score with the inputs attached
New contacts get an ICP fit score plus a JSON blob of the signals behind it, so a rep can see why a lead scored 82 instead of trusting the number.
Assign on enriched territory
Segment and headcount resolved in Clay, owner assigned by the orchestrator — never by Clay writing the owner field directly, so round-robin state stays in one place.
The one that needs a custom build
A researched trigger event should create a HubSpot task for the owner. The connector cannot do it, so we write it through the HubSpot API with idempotency keys and a dead-letter queue.
Two architectures. One is documented, one is ours.
Native scheduled sync is what Clay supports out of the box and it is fine for backfill. Event-driven architecture is what you need when a decision has to happen while the prospect is still on the page — and it is a build, not a setting.
Documented by Clay
Cost: the whole population every run. Good for backfill, scoring refresh and hygiene.
RevPack reference architecture
Cost: one row per event. Good for routing, speed-to-lead and task creation.
A is Clay's documented native behaviour. B is a custom architecture we build — it is not a Clay feature. We usually build it in n8n.
The constraints, stated plainly
Where a number is published, we cite it and date it. Where it is not, we say so rather than guess.
The integration inherits the authorising user's HubSpot permissions. If that user can edit deal amounts, so can the integration — which is the argument for a dedicated integration user with a scoped role.
Both vendors publish SOC 2 Type 2 attestations and offer a DPA covering EU processing. Confirm the current scope of each against the vendors' own trust pages before signing — we do not restate certification detail that can lapse.
Clay + HubSpot, answered.
Does Clay integrate with HubSpot?
Yes, natively, over OAuth. You import HubSpot records into a Clay table, enrich them, and write results back to the same records.
Is the integration bidirectional?
It reads and writes, so yes — but not as a mirror. Data flows out of HubSpot on a schedule and back under conditions you define. There is no continuous two-way replication, and you should not design as if there were.
Which HubSpot objects does Clay support?
Contacts, companies and deals, plus custom objects whose schema already exists in your portal. See the coverage table above.
Does Clay support HubSpot custom objects?
Yes, for read and write, once the object and its properties are defined in HubSpot. Clay will not create the schema for you.
Does Clay support HubSpot tasks?
Not as a native object in the connector. Creating or updating tasks requires a custom HubSpot API workflow, which is one of the more common things we build on top of this integration.
How do I avoid duplicates when updating HubSpot from Clay?
Match on HubSpot Object ID rather than email or company name, and configure the write as update-if-found, create-if-not. Keep the ID column in the table and never let an enrichment overwrite it.
Can Clay overwrite existing HubSpot values?
It can, which is why field-level ownership matters. Set skip-if-empty on every mapped property and restrict overwrite rights to fields Clay genuinely owns. There is no built-in arbitration if you do not.
How often does Clay sync with HubSpot?
Every 24 hours by default. Daily on Growth-tier subscriptions and as frequently as every 15 minutes on Enterprise. Cadence is plan-gated, not a Clay setting you can raise on its own.
Can Clay react to HubSpot changes in real time?
Not through the scheduled sync. For second-level response you put an orchestration layer between them: a HubSpot webhook fires, the orchestrator calls Clay for a single row, and the callback writes back. That is architecture B above.
What are the Clay HubSpot API limits?
Clay does not publish per-connector rate limits; in practice they inherit HubSpot's platform API limits, which depend on your subscription tier. We measure the ceiling against your portal rather than quoting a figure.
Bring your HubSpot property list and one Clay table.
Two weeks. You leave with a field ownership schedule, a mapping spec keyed on Object ID, and a decision on whether you need the event-driven architecture or the native sync is enough — whether or not you build it with us.