Clay to HubSpot integration: setup, field mapping, and fixes

A complete Clay to HubSpot integration guide for Microsoft partners: field mapping, dedup logic, and fixes for the syncs that quietly break pipeline.
Jackson Tarrant
Head of Growth
Clay to HubSpot integration: setup, field mapping, and fixes

Last updated:

August 18, 2026

Most Clay to HubSpot integrations look fine on day one and start leaking on day thirty. The enrichment runs, records appear in HubSpot, and everyone assumes the pipe is clean. Then duplicate contacts pile up, a mapped field silently stops writing, and Clay credits burn on records you already had.

This guide covers the full setup, then goes where most tutorials stop: the field mapping decisions that prevent dedup chaos, and the troubleshooting steps for when a sync breaks in production. There is a copy-ready checklist near the end you can run against your own instance.

What a clean Clay to HubSpot sync requires

A working integration is not just connected. It writes the right fields, to the right object, without creating a second version of a contact you already own.

Three things decide whether it holds up:

  • A single source of truth for identity, usually email, sometimes a composite key
  • Explicit field mapping, written down before you connect anything
  • A dedup rule that Clay and HubSpot both respect, not one rule each

Get those three right and most of the classic failures never happen.

Field mapping decisions to make first

Mapping is where integrations quietly go wrong, so decide it on paper before you touch a connection. For every field Clay will push, answer three questions: which HubSpot property receives it, what happens on conflict, and whether it should ever overwrite a human-entered value.

The decisions that matter most:

  • Match on email as the primary identifier, and only fall back to a composite key of name, company, and domain when email is missing.
  • Never let enrichment overwrite fields your sales team edits by hand, like lifecycle stage or deal notes.
  • Map company data to the company object, not the contact, so you do not duplicate firmographics on every contact.
  • Set default values for empty enrichment so you never write blanks over good data.

Clay to HubSpot setup, step by step

1. In HubSpot, create or confirm the custom properties Clay will write to. Name them clearly, for example "Clay job title" versus the native title field, so you can audit what came from enrichment.

2. In Clay, add the HubSpot integration and authenticate with an account that has write access to contacts and companies.

3. Choose the object you are writing to, contact or company, and set the matching field to email or your composite key.

4. Map each Clay column to its HubSpot property. Set update behavior per field: update, or write only if empty.

5. Turn on dedup. Match on email, and set Clay to update the existing record rather than create a new one.

6. Run a 10-record test batch before the full run. Confirm records update in place and no duplicates appear.

7. Only after the test passes, run the full list and enable any scheduled refresh.

The test batch is the step everyone skips and everyone regrets. Ten records cost almost nothing and expose a bad mapping before it touches thousands of contacts.

Field mapping and dedup checklist

Run this against your instance before you trust the sync. This is the asset to gate behind a form for lead capture.

Identity and dedup:
  • Primary match key set to email
  • Composite fallback defined for missing emails
  • Clay set to update existing records, not create new ones
  • HubSpot dedup settings reviewed for the same object
Field mapping:
  • Every Clay column mapped to a named HubSpot property
  • Enrichment fields kept separate from human-edited fields
  • Overwrite behavior set per field, never a blanket overwrite
  • Company data written to the company object
  • Empty-enrichment default values defined
Credits and safety:
  • Test batch of 10 run and verified
  • Enrichment filtered to only records missing data
  • Refresh schedule set to skip unchanged records

Troubleshooting broken syncs

When the sync misbehaves, work through these in order.

Duplicate contacts appearing. Your match key is wrong or inconsistent. Confirm Clay matches on email and is set to update, not create. Check for trailing spaces or casing differences that make two identical addresses look distinct.

A mapped field stopped writing. The HubSpot property was renamed, deleted, or changed type, for example from single-line text to dropdown. Re-open the mapping and re-point the field. Type mismatches fail silently more often than they throw an error.

Credits burning faster than expected. You are enriching records that already have data, or re-enriching on every run. Filter the source so Clay only touches records missing the target fields, and set the refresh to skip unchanged rows.

Dedup logic that fails intermittently. Two systems are both trying to own identity. If HubSpot merges by email and Clay matches on a composite key, they will disagree. Align both on the same key.

Records update in Clay but not HubSpot. This is almost always a permissions or auth issue. Re-authenticate with an account that has write access to the object you are targeting, and confirm the property is not read-only.

When the sync should run itself

You can maintain this by hand. Many teams do, and this guide is enough to keep a clean pipe if someone owns it every week.

The teams that stop maintaining it are usually running enrichment as one input into a larger motion: identify the accounts worth pursuing, find the right people inside them, and reach only those contacts with a message that fits. That is the engine we run for Microsoft partners as a managed service, so the sync, the dedup, and the routing are handled, and the pipeline is the deliverable instead of the tooling.

If your Clay to HubSpot setup is technically connected but not producing meetings, that is the conversation to have.

Contents