How to Integrate Airtable with HubSpot

HubSpot and Airtable are not competitors. They solve different problems. HubSpot is the system of record for the sales motion — contacts, conversations, sequences, deals, the email-tracking infrastructure that sales reps live in. Airtable is the system of record for everything that happens around and after sales — project delivery, custom client data, operational workflows, the long tail of objects HubSpot's data model can't model cleanly.

The integration between them is rarely "sync everything." It's "sync the right slice." This guide covers the four real patterns we build for clients and the architecture decisions behind each.

Pattern 1: Contact & Company Sync (HubSpot → Airtable)

The most common starting point: HubSpot is canonical for contacts and companies, and Airtable mirrors them so they can be linked to Airtable-side objects (projects, invoices, accounts).

Architecture

• Source of truth: HubSpot.
• Direction: HubSpot → Airtable only.
• Trigger: New or updated HubSpot contact/company.
• Airtable mirrors: Read-only or restricted editing.

Setup with Make

1. Trigger: HubSpot Watch contacts (or Watch companies). Set the watch to "created or modified."
2. Search: Airtable Search records in your Contacts table by HubSpot ID equal to the triggered contact's ID.
3. Router:
   • If found → Airtable Update record with the new field values.
   • If not found → Airtable Create record with the contact data and the HubSpot ID.

Critical fields to sync

Skip syncing fields that don't drive Airtable-side workflows. The more fields you sync, the more conflict logic you need.

Pattern 2: Deal-to-Project Handoff (HubSpot → Airtable)

The pattern that pays back the integration on day one: when a HubSpot deal moves to "Closed Won," a project record is created in Airtable with all the deal metadata, and operations takes over from there.

Setup

1. Trigger: HubSpot Watch deals filtered to dealstage = closedwon.
2. Get associated data: Fetch the contact and company linked to the deal.
3. Airtable Create record in your Projects table:
   • Project Name = Deal Name
   • Client = lookup of the Company in Airtable
   • Primary Contact = lookup of the Contact in Airtable
   • Budget = Deal Amount
   • Sold Date = Deal Close Date
   • HubSpot Deal ID = stored for future updates
4. Slack/email notification to the delivery team that a new project landed.

This is one of the highest-leverage automations a services business can build. The handoff that used to involve a manual Slack message, a "kick-off doc," and three back-and-forths is now a single trigger.

For the full pattern, see our automate client onboarding with Airtable and Make guide.

Pattern 3: Airtable → HubSpot Updates (Operations → Sales)

Less common but important: operations updates the project status in Airtable, and HubSpot deal records reflect it so the sales team always knows where delivery stands.

Setup

1. Airtable automation triggered when project Status changes.
2. Webhook action that calls Make.
3. Make scenario: HubSpot Update deal using the stored HubSpot Deal ID, writing to a custom HubSpot property like "Delivery Status."

For sales-facing visibility, this beats asking ops to log into Airtable. The information lives where sales already looks.

Pattern 4: Reporting Consolidation

When leadership wants a single dashboard showing pipeline (HubSpot) + delivery (Airtable) + revenue (Airtable/QuickBooks), the cleanest pattern is:

1. Sync HubSpot deal data into Airtable as a read-only mirror.
2. Build the consolidated dashboard in Airtable Interface Designer or Looker Studio.

Don't try to build the reporting in HubSpot — its reporting layer is built for sales, not cross-functional ops. Bring HubSpot data to Airtable for cross-system reporting.

Tool Comparison: How to Build the Integration

For 80% of teams, the right answer is Make. Our automate Airtable with Make guide walks through the platform.

Architecture Decisions That Matter

Pick a source of truth per object

For every object you sync — contact, company, deal — pick which tool owns it.

• Contacts and companies: HubSpot. Marketing and sales own them.
• Deals (in pipeline): HubSpot. Until they close.
• Closed deals (as projects): Airtable. Delivery owns them post-close.
• Invoices, projects, tasks, custom workflows: Airtable.

A clear ownership map is the difference between a clean integration and a permanent sync war.

Use IDs, not names, as join keys

Every Airtable record that mirrors a HubSpot object needs a HubSpot ID field. Every HubSpot object that mirrors an Airtable record needs an Airtable Record ID custom property. Sync on IDs, never on email or name — those change.

Field-level direction

For shared fields (e.g. Contact Lifecycle Stage), decide if HubSpot or Airtable wins. Document this in your Make scenario's description. When the inevitable conflict happens, the architecture answers it.

One scenario per direction per object

Don't build "the everything syncer." Build:

• HubSpot Contacts → Airtable Contacts
• HubSpot Companies → Airtable Companies
• HubSpot Closed-Won Deals → Airtable Projects
• Airtable Project Status → HubSpot Deal "Delivery Status"

Each is its own scenario. When one breaks, you fix one. When one needs to change, you change one.

Common Mistakes

Mistake 1: Two-way sync on every field. Most teams don't need it. Pick a source of truth per field, sync one way, and accept that the other side is read-only for that field.

Mistake 2: Forgetting HubSpot's API rate limits. HubSpot's API limits to 100 requests per 10 seconds for most plans. Bulk syncs need to throttle. Make's "throttle" helper module handles this; in custom code, add delays.

Mistake 3: Syncing every HubSpot contact. HubSpot databases often hold tens of thousands of contacts you don't need in Airtable. Filter at the trigger — only sync contacts in specific lifecycle stages or with specific tags.

Mistake 4: Not storing IDs both ways. Without HubSpot ID on the Airtable record and Airtable Record ID on the HubSpot object, every "update" creates a new record. Duplicate explosion follows.

Mistake 5: Treating HubSpot's custom objects as the answer. HubSpot custom objects are expensive (Enterprise only) and the schema is rigid. If you need custom objects, Airtable is almost always the better home.

Troubleshooting

Sync runs but fields don't update. Check the Make module's field mapping — HubSpot field internal names differ from labels. firstname not First Name.

Duplicate contacts appearing in HubSpot. Your Airtable → HubSpot scenario is creating instead of upserting. HubSpot's Create or update contact action uses email as the dedup key — confirm the email field is populated before the action runs.

Rate limit errors mid-scenario. Add a throttle module set to 9 requests/second. For batch syncs of >1,000 records, split into multiple runs scheduled hours apart.

Deal-to-project automation creates duplicates. The closedwon trigger fires on every stage change, not just the transition. Add a filter on HubSpot Deal ID not already existing in Airtable Projects.

Webhook from Airtable fires but Make scenario doesn't run. The scenario isn't enabled, or the webhook URL is wrong. Verify in Make's scenario run history.

Next Steps

HubSpot integration is rarely a one-off project. Most teams end up with 4–6 distinct scenarios over six months as they discover the right level of integration. Start with one pattern, run it for a month, then add the next.

If you're building this alongside other CRM integrations, see our Salesforce integration guide and the Airtable CRM build guide. When the integration design needs to span sales, ops, finance, and reporting cleanly, we scope and build the full pipeline. Get in touch and we can walk through it.