HubSpot and Airtable, synced in one direction per field
How to keep HubSpot and Airtable in step: which system owns each field, how records are matched across the two, what happens on a merge or a delete, and four ways to build the sync with the cases each suits.
The pairing makes sense when HubSpot owns the selling record and Airtable holds an operational shape HubSpot does not: many-to-many relationships, rollups across them, and interfaces for people who should never see the CRM. Contacts and companies flow one way into a base of projects, sites or products; a few delivery facts flow back for sales to see.
It is also the pair where two-way sync is attempted most and regretted most. Both tools have friendly editors and both look like databases, so everyone wants to correct a value wherever they happen to be standing. The design question is therefore not how to sync, it is which system owns which field. Once that is written down, the engineering is routine; without it, no tool will keep the two honest.
Decide ownership before building anything
A worked example of the matrix we write first. Yours will differ; the rule that every field has exactly one owner will not.
| Field group | Owner | Direction | Why |
|---|---|---|---|
| Name, email, phone, lifecycle stage | HubSpot | HubSpot to Airtable | Sales edits these. The Airtable copy is read-only so nobody corrects a value that is about to be overwritten. |
| Company and contact association | HubSpot | HubSpot to Airtable | Becomes a linked record, built from IDs, never from names. |
| Project status, site address, install dates | Airtable | Airtable to HubSpot | Delivery edits these. HubSpot shows them in properties that sales can read and should not edit. |
| Deal owner | HubSpot | HubSpot to Airtable | Matched across the two by email address, since the IDs differ. |
| Notes and call logs | Neither | Not synced | Free text with consent and privacy implications. Link to the record rather than copy it. |
How to build the sync
In rising order of control and cost to maintain.
HubSpot's own data sync app
HubSpot's Data Sync app connects a HubSpot account to an Airtable base and maps records and properties between them, and Airtable's support pages describe it as the two-way option alongside HubSpot workflows. It is the lowest-effort route, but it needs a paid HubSpot Data Hub subscription, and the sync rules and the supported objects and field types are HubSpot's, not yours. Confirm the plan, the objects, the sync direction per property and how often it runs in the current HubSpot and Airtable documentation before relying on it, and still decide field ownership first.
Choose it whenStandard contacts and companies need to appear in a base, the supported fields cover what you need, and no custom logic is required.
A Make or n8n workflow
A trigger on the HubSpot side, a fetch, a transformation, and an upsert into Airtable keyed on the HubSpot record ID. It handles conditional logic, reshaping and the reverse direction, and it is where most of these syncs sit. Cost depends on the platform: credits per module run on Make, executions on n8n.
Choose it whenFields need transforming, only some records qualify, or a few properties must flow back.
A HubSpot workflow that sends a webhook
A HubSpot workflow fires when a record meets a condition and posts a chosen set of properties to an endpoint, which upserts into Airtable. The condition lives in HubSpot, where the sales team can see it. The workflow webhook action sits on the higher paid tiers, so check HubSpot's current knowledge base for yours.
Choose it whenA single, well-defined event should create or update an Airtable row, and the people who define the event work in HubSpot.
A small service with a queue
An application that reads in batches, honours both APIs' limits with a queue, records what it has synced, and resolves conflicts deterministically. More to build, but retries become idempotent and the sync is observable in a way a scenario's run history is not.
Choose it whenVolumes are large, two-way sync on any field is genuinely required, or the sync is load-bearing enough that an unexplained gap is costly.
The HubSpot to Airtable direction, in order
The reverse direction is the same steps with the systems exchanged, plus the guard against echoes described below.
- 01
Detect the change
A webhook subscription on the property or object event, or a poll that filters on last-modified date. Webhooks give you the changed property but not the rest of the record, and a form submission that sets a dozen properties can produce a dozen events for one contact.
- 02
Fetch the current record
Read the record and its associations fresh, using batch reads where the API offers them. Do not trust the value in the event: HubSpot does not guarantee delivery order, so use the event's occurred-at time rather than arrival order, and read the state as it is now.
- 03
Shape the values
Translate each property to the Airtable field's type: internal option values to select names, semicolon-separated multi-selects to arrays, empty strings to null, dates to the timezone you have chosen. The mapping table below is where this goes wrong.
- 04
Upsert on the HubSpot record ID
Write to Airtable with an upsert merging on a dedicated HubSpot ID field. Running the same event twice must leave one row. Writing a plain create here is how duplicates start.
- 05
Resolve links in a second pass
A contact's company link needs the Airtable record ID of that company, found by looking up the HubSpot company ID. If the company has not been synced yet, the link has nothing to point at. Sync companies first, or hold the link and fill it once the target exists.
- 06
Write the Airtable record ID back, if HubSpot needs it
Storing the Airtable record ID in a unique-value HubSpot property lets the reverse direction find its record by lookup instead of search. It is also what lets you reconcile the two sides later.
Where the sync actually breaks
Almost every failure on this pair is one of these rows. The tools agree about almost nothing.
| Concept | In HubSpot | In Airtable | Rule |
|---|---|---|---|
| Record identity | A numeric record ID, returned as a string. | An opaque record ID beginning rec. | Store the HubSpot ID in an Airtable field and merge on it. Store the Airtable ID in a unique-value HubSpot property. |
| Associations | Many-to-many, optionally labelled. | A linked-record field holding an array of record IDs. | Write the full array each time, because writing a partial array replaces the set. Build it from IDs. |
| Dropdowns | An internal value, such as a lowercase token, with a separate display label. | A single select identified by its name. | Map internal values to names explicitly. Allowing the API to create new options on the fly makes a quiet sprawl of near-duplicates. |
| Multi-select | One string with items separated by semicolons. | An array of names. | Split and join at the boundary, and trim whitespace. |
| Dates | Date properties stored as midnight UTC; date-times as timestamps. | A date field with an optional time and timezone. | Convert deliberately. A date-only value read in a local timezone shows up a day early. |
| Empty values | An empty string. | Null or an absent field. | Send null to clear an Airtable field. An empty string is a value in its own right, and some field types will reject it. |
| Numbers and currency | Returned as strings. | Number and currency fields. | Parse, and be explicit about precision and the currency code. |
| Owner | A numeric owner ID. | A collaborator, matched by email. | Resolve through the owners list by email. IDs mean nothing across the two systems. |
| Calculated fields | Calculated properties. | Formula, rollup and lookup fields. | Never write to these. If Airtable can compute a value, compute it there and do not sync it. |
What goes wrong with HubSpot + Airtable
The patterns that turn up on this pair specifically, and what we do about each one.
- 01
A merge in HubSpot leaves the Airtable row pointing at nothing
When two contacts are merged in HubSpot, one ID stops existing. The Airtable row keyed on it either becomes an orphan or, on the next sync, is recreated as a new row beside the survivor. Subscribe to merge events or read the merged-IDs property on the surviving record, then re-point or archive the old row, and treat the reconciliation pass as part of the build.
- 02
Deletes that cascade through links
Archive in HubSpot and delete in Airtable are not the same thing. Deleting a company row removes the link from every linked project and silently changes every rollup that read through it. Mark rows as archived with a field and filter the views, rather than deleting, and only delete once nothing links to the row.
- 03
Two-way sync and the echo
A change in Airtable writes to HubSpot, HubSpot emits an event, the sync writes it back to Airtable. At best it wastes calls; at worst two edits made seconds apart overwrite each other. Break the cycle by field ownership, by comparing against the last value written before writing, and by recording a last-synced timestamp so an event produced by the sync itself can be recognised and dropped.
- 04
Airtable's write limits, met during the first load
Airtable takes ten records per create or update call and limits requests per base. As an illustration, a first load of 20,000 contacts is 2,000 calls at ten records each, and at the five requests a second per base that Airtable documented when we checked, that is about seven minutes of perfect packing, before retries. Chunk, wait on the rate-limit response (Airtable documents a 30-second wait after a 429), and make the load resumable so a failure at call 1,400 does not restart at call one. Check the current limits in Airtable's documentation before sizing.
- 05
Duplicates faithfully copied
A sync keyed on HubSpot ID copies HubSpot's duplicates precisely: the same person twice, now in two places, with links split between the copies. Merge in HubSpot first and sync afterwards. Fixing it downstream means fixing it twice.
- 06
Credits multiplied by events
A per-event Make scenario costs a trigger, a fetch, a search and an upsert, so about four credits for each event, and one form submission can raise an event per property set. Narrow the subscription to the properties that matter, debounce events for the same record inside a short window, or poll for changes in batches. The saving is usually larger than anything gained by tuning the modules.
- 07
Consent follows the copy
Copying contacts into a base people can export from creates a second place where an unsubscribe has to be honoured. Sync the marketing-consent state alongside the contact, make it read-only, and keep anyone from emailing out of Airtable. This is a design point rather than legal advice, and your obligations depend on your jurisdiction.
A won deal becomes a project row, exactly once
The set-up
Illustrative, not a client result. Sales close in HubSpot. Delivery plans in Airtable, where a Projects table links to Companies. The trigger is a deal reaching closed-won.
What it comes to
Around five API calls per won deal, small beside the limits both vendors publish, which are still worth checking. Replaying the same webhook finds the same two rows and changes nothing, and if the company is merged in HubSpot next month the reconciliation pass has an ID to follow.
- 01
HubSpot workflow posts a webhook
On entering closed-won, with re-enrolment off, the workflow sends the deal ID to the sync.
- 02
Fetch the deal with its company and primary contact
One deal read plus its associations, so the sync works from the current state and not from the payload.
- 03
Upsert the company, then the project
Company merged on the HubSpot company ID. Project merged on the HubSpot deal ID, with its company link filled from the company row's record ID.
- 04
Write the project's record ID back to the deal
A unique-value property on the deal now holds the Airtable ID, and a read-only delivery-status property is the only thing that will flow back from Airtable.
When not to sync them at all
If Airtable is only there to show HubSpot data on a nicer grid, the sync is the wrong project. Use HubSpot's own reports and dashboards, or HubSpot's data sync app if you need the data in a base. A second copy of the data is a cost whenever there is no operational logic on top of it.
Do not sync a field in both directions. If you cannot name an owner, the fix is a conversation, not a cleverer sync. And if the ops data is genuinely relational and transactional, the right destination may be a database with an application over it, not a base; the Airtable platform page sets out where that line is.
Think twice about volume. A very large contact table copied into Airtable can run into the per-base record limit for your Airtable plan and slow its views, for no operational benefit. Sync the subset ops actually works with, which is usually customers rather than every contact ever created.
Projects that did not use HubSpot + Airtable
Here for the argument rather than as evidence of this integration. Each one bears on a point above, and the note says which.
- Blueprint RunnerBlueprint Runner: a self-hosted engine that speaks Make nativelyNot a HubSpot build. Its Airtable actions cover search, create, update and upsert against the REST API, and its self-test exercises deduplication through a merge filter and a linked-record append, so it is the closest thing we have to evidence on the Airtable half of this pair.Case study
- A commercial solar installerAn ops platform where the building is the record, not the dealNot a HubSpot or Airtable build. It is the case for what an operational record should model: the record there is a building, not a deal, and one negotiation opens a project per roof, which is the reason an ops record cannot simply live as a CRM deal.Case study
The disciplines behind it
Related reading
Rate limits, plan tiers and which modules exist change over time. Where this page gives a figure it shows how it was derived; for everything else, confirm against the vendors’ current documentation before sizing a build. Skofi holds no partnership, certification or reseller arrangement with any vendor named here.
HubSpot + Airtable, specifically
Yes, from HubSpot's side: its Data Sync app connects to Airtable, and Airtable's support pages cover it alongside HubSpot workflows. It needs a paid HubSpot Data Hub subscription, and the objects, field types and sync rules are HubSpot's, so check the current documentation. Airtable's own sync feature produces read-only synced tables, but we have not confirmed HubSpot as one of its sources. For anything that needs custom ownership rules or reshapes data on the way, you need a workflow tool or a small service.
Yes, on different fields. Two-way on the same field is the design that fails, because both sides will eventually be edited within the same few seconds and one change will be lost. Give each field one owner, sync in that direction, and make the receiving side read-only for it.
Not if every write is an upsert keyed on a stable ID. Duplicates come from plain creates being retried, from keying on email when a person has two, and from copying duplicates that already exist in HubSpot. Merge in HubSpot first, then sync.
Longer than the arithmetic suggests. Airtable accepts ten records per call and limits requests per base, so 20,000 records is 2,000 calls and at least several minutes before back-off. The real constraint is making it resumable, so a failure partway through does not mean starting again. Check both vendors' current limits before planning a window.
Nothing, unless the sync handles it. Association changes are events like any other; if the sync does not subscribe to them, the Airtable link stays stale. Decide whether links are rebuilt on every sync of the record or only on association events, and always write the full array so removals take effect.
It depends on the build. A scoped private app and the CRM APIs are available broadly, while workflow webhooks sit on higher workflow tiers and the limits differ by tier. We confirm what the current plan allows before choosing the build, because it changes which option is cheapest.
Sources
Statements about what a platform, regulator or provider says come from their own pages. Rules and limits change, so check the current page before you rely on one.
- Integrating HubSpot with Airtable · Airtable (Support)
- Connect and use HubSpot data sync · HubSpot (Knowledge Base)
- Rate limits · Airtable (Web API)
- API usage guidelines and limits · HubSpot (Developer Docs)
- Properties API · HubSpot (Developer Docs)
- Webhooks v3 API guide · HubSpot (Developer Docs)
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no