Connect HubSpot and Airtable

In short

Connecting HubSpot to Airtable lets sales keep working in the CRM while delivery runs in a base built for operations. The difficulty is two-way sync: without loop protection and stable record matching, updates ping-pong between systems and duplicates accumulate. SBD builds this with a defined field ownership model on each side.

The workflows

What runs between HubSpot and Airtable.

Each line is one automated workflow. An event in one tool, the checks and mapping in between, the action in the other, and the person who hears about it.

1. Sales-to-delivery handoff without a re-keying step

   When

   Deal reaches closed-won in HubSpot

   Automation

   • Verify and validate
   • Map and normalise
   • Upsert by key

   Then

   Create the delivery project in Airtable with owner, scope and dates populated

   And

   • Audit log entry
   • Alert if it fails or goes quiet
   • Review queue if unsure

2. Delivery status visible in the CRM without giving delivery CRM seats

   When

   Delivery milestone updated in Airtable

   Automation

   • Verify and validate
   • Map and normalise
   • Upsert by key

   Then

   Write status back to the HubSpot deal so sales can see progress without asking

   And

   • Audit log entry
   • Alert if it fails or goes quiet
   • Review queue if unsure

3. Reporting that joins pipeline data with delivery reality

   When

   Contact or company updated in HubSpot

   Automation

   • Verify and validate
   • Map and normalise
   • Upsert by key

   Then

   Update the linked Airtable records, matched on HubSpot object ID

   And

   • Audit log entry
   • Alert if it fails or goes quiet
   • Review queue if unsure

4. Renewal triggers driven by delivery milestones

   When

   Project completed in Airtable

   Automation

   • Verify and validate
   • Map and normalise
   • Upsert by key

   Then

   Log the activity against the deal and trigger the renewal or upsell sequence

   And

   • Audit log entry
   • Alert if it fails or goes quiet
   • Review queue if unsure

Every record passes through the same stages

1. 1Receive

   Webhook or polling from the source tool, with a signed payload and a replay log.

2. 2Validate

   Required fields present, types right, record key found. Anything else goes to the review queue.

3. 3Map

   Fields translated to the destination schema. Enumerations, currencies and dates normalised.

4. 4Upsert

   Written against the record key, so a retry updates rather than duplicates.

5. 5Confirm

   Outcome logged. Alert if the count goes quiet. Reconciliation run nightly.

Read this first

Why the obvious route breaks.

A one-step Zap connects HubSpot and Airtable in an afternoon. This is what goes wrong once real volume and real edge cases arrive.

• Two-way sync loops without a guard

  An Airtable edit updates HubSpot, which fires a HubSpot webhook, which updates Airtable, which fires again. Without marking system-originated writes and skipping them on the return trip, this runs until something rate-limits.

• HubSpot associations have no Airtable equivalent

  Contacts, companies and deals are associated objects in HubSpot. Flattening them into one Airtable table loses the relationships; recreating them needs linked tables and a matching strategy that survives records being merged in HubSpot.

• Email is not a reliable primary key

  Most quick integrations match on email. People change addresses and HubSpot merges duplicates, so matching on email eventually attaches the wrong activity to the wrong contact. HubSpot object IDs are the only stable key.

• Nobody defines who owns which field

  When both systems can write deal stage, the last writer wins and the pipeline becomes untrustworthy. Field ownership has to be an explicit decision, not an emergent one.

What it costs today

The gap, as the team feels it and as the engineer sees it.

What we wire up

The data flows.

1. 01
   When

   Deal reaches closed-won in HubSpot

   Then

   Create the delivery project in Airtable with owner, scope and dates populated

2. 02
   When

   Delivery milestone updated in Airtable

   Then

   Write status back to the HubSpot deal so sales can see progress without asking

3. 03
   When

   Contact or company updated in HubSpot

   Then

   Update the linked Airtable records, matched on HubSpot object ID

4. 04
   When

   Project completed in Airtable

   Then

   Log the activity against the deal and trigger the renewal or upsell sequence

Data map

What becomes what, and what it is keyed on.

Field-level mapping is agreed in the blueprint and written into the runbook. Two-way rows carry loop protection so a write from the sync never re-triggers the sync.

In every build

What you get with the sync, whichever pair.

Security and your data

Where the data goes, and who holds the keys.

Accounts

Every platform account is created in your name. We work through managed access you can revoke.

Credentials

Stored encrypted in the orchestration layer. Scoped per connection. Rotated on handover.

Data in transit

TLS everywhere. Webhooks verified by signature before anything is processed.

Data at rest

Only what the sync needs. No copies of your customer data on our machines.

AI steps

Where an integration uses a model, it is through a business API that does not train on your data.

Retention

Run logs kept 90 days by default, adjustable. Payloads redacted of card and ID numbers.

Agreements

DPA and NDA on request. Regional rules covered in our privacy policy.

Keys and sensitive data

How API keys, tokens and personal data are handled.

• Keys live in a vault, never in code

  API keys and tokens are stored in the orchestration layer's encrypted credential store or the platform's secret manager. None are written into workflows, repos, spreadsheets or chat.

• One credential per connection

  Each integration gets its own key, scoped to the objects and actions it needs. A lead sync cannot read invoices. Revoking one key stops one thing.

• Service accounts, not personal logins

  Connections use a dedicated service user in your account, so nothing breaks when a person leaves and nothing runs under someone's name.

• Two-factor on every account

  Every platform account we set up has two-factor authentication on, with recovery codes handed to you, not kept by us.

• Rotation on handover and on request

  Keys are rotated when the build is handed over, when anyone with access leaves, and at any time you ask.

• Secrets never reach the logs

  Audit logs redact tokens, card numbers, government IDs and anything you flag as sensitive before a line is written.

• Webhooks verified before processing

  Inbound calls are checked against the sending tool's signature. Unsigned or stale payloads are dropped and counted.

• Access you can see and revoke

  Our access is through managed roles in your accounts. You can list it, limit it, and remove it in one click without touching the build.

Engineering decisions

Decided before the first workflow is written.

• Rate limits and backoff

  Every API has a ceiling. Calls are batched, queued and retried with increasing delays so a busy hour does not become a failed one.

• Backfill and pagination

  The first run has to load history, not just new events. Backfills page through the source in order, resume after interruption, and never double-write.

• Out-of-order and duplicate events

  Webhooks arrive twice and out of sequence. Each event carries a version or timestamp, and older versions never overwrite newer state.

• Schema changes

  A renamed field or a new dropdown value is the most common silent failure. Payloads are validated against a contract, and a mismatch stops the run and raises a flag.

• Time zones, currencies, units

  Dates are stored in UTC and shown local. Money carries its currency. Quantities carry their unit. Conversions happen once, in the map step.

• Sandbox first

  Builds run against sandbox or test accounts with seeded data before they touch production. Go-live is a switch, not a rewrite.

• Versioned and reversible

  Workflows and code are version-controlled. A release can be rolled back in minutes without losing the records processed since.

• API deprecations watched

  Tools retire API versions on a schedule. We track the dates for every connection in the runbook and upgrade before the cut-off.

• Cost per run known

  Each workflow has a cost per execution, including any model calls, logged alongside the run. You see the bill before it arrives.

• Metrics, not just errors

  Runs per hour, records in and out, exception rate and latency are charted. Trends show a problem before an alert does.

Questions

What people ask about this pair.

Related

• +

  Pipedrive and Airtable

  Close the deal in Pipedrive, run the work in Airtable, and keep both honest.

• +

  HubSpot and Slack

  Notifications people act on, rather than a channel that gets muted in week two.

• +

  Airtable and Retool

  Airtable is a good database and a limited interface. Retool fixes the second half.

• Solution

  Consulting and agencies

  Every workflow we automate for this kind of team.