Most integration guides in this series open by explaining that the native connector does less than the marketing suggests. This one has to start somewhere stranger, because on paper the HubSpot Airtable integration is unusually privileged. HubSpot built it rather than leaving it to a third party. It is a certified app. And Airtable belongs to a club of six applications that HubSpot data sync will synchronise custom objects with, which is a genuinely short list in an ecosystem of well over a thousand listings.
Then you read the next paragraph of the same documentation. When syncing with a custom object, HubSpot states, associations will not be maintained, and recommends mapping them manually instead.
Sit with that pairing for a moment, because the whole guide follows from it. The rare privilege is real. It carries records of a shape almost no other app is trusted with. What it does not carry is the thing that makes those records mean anything: the links between them. And on the Airtable side the same asymmetry shows up from the opposite direction, because the fields that turn linked records into a usable number, the formulas and rollups and lookups, are read only in Airtable's own API and cannot be written to at all.
Airtable's entire value proposition is that it is not a spreadsheet. It is a small relational database with a friendly surface, and the links are the product. HubSpot's own marketplace listing describes the Airtable side of the sync, in the data source column, as "records in a sheet." Both companies are being accurate. They are just describing different halves of the same tool. This guide covers what actually crosses in each direction, the three plan gates in three different places, the setup requirements that silently decide whether a field appears at all, and the one throughput ceiling in this whole category that no amount of money will lift. It sits alongside the broader guide to HubSpot integrations.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Why Teams Connect HubSpot and Airtable at All
Airtable tends to arrive in a company sideways. Nobody procures it. Somebody in marketing or delivery or partnerships needs to track a kind of thing the CRM does not model, builds a base in an afternoon, and eighteen months later that base is load-bearing. Content calendars, implementation projects, inventory, event logistics, applicant pipelines, property portfolios, research studies. HubSpot classifies its own Airtable app under Project Management, which is a fair read of how most teams actually use it.
That origin story is why the integration question arrives late and arrives urgently. The base was never designed to talk to the CRM, and then one day the same customer exists in both places, with a different name in each, and somebody is reconciling by hand every Friday afternoon.
The other reason this pairing comes up more than most is that Airtable is doing a job HubSpot deliberately does not do. HubSpot models the commercial relationship. Airtable models the work. The HubSpot ClickUp integration guide covers the same seam from the project management side, and the pattern repeats: the CRM knows the deal closed, and something else has to know what to do about it.
Does HubSpot Integrate With Airtable?
Yes, and the provenance is better than most of this category. The app is built by HubSpot, listed as a HubSpot Certified App, and runs on HubSpot data sync rather than on a third-party middleman. If you have read the HubSpot Operations Hub guide, this is the same engine described there, pointed at a base instead of a CRM.
What the listing also gives you is something most vendor pages hide, which is what the people using it think.
Quoting a vendor's own published aggregate is worth doing precisely because it is not a review site's opinion. HubSpot is publishing this about software HubSpot wrote. And the review themes it surfaces are not complaints about bugs. Ranked by volume they are sync reliability, ease of setup, field mapping complexity, supported object types, field type limitations, and documentation. Read as a group, that is a scope problem wearing a reliability costume: the sync does what it says, and what it says is narrower than what a base contains.
There is one gate to check before anything else, because it is stricter here than the data sync norm.
Worth noting a documentation gap while you are here, because it will mislead you if you start on the wrong side. Airtable's own help centre still describes this as HubSpot's "Data sync beta feature" and scopes it to syncing contact and company information. HubSpot's listing shows twelve objects across two directions. The HubSpot side is the current one. When two vendors document the same integration, the one who built it is usually the one to trust.
What the HubSpot Airtable Integration Actually Syncs
Here is the detail that decides most architectures and that almost no write-up mentions, because it is encoded in two small direction icons on the marketplace listing rather than in prose. The objects are not all equal. They fall into two groups with two different direction arrows.
| Sync direction | Objects | |
|---|---|---|
| Group one | Two way, Airtable and HubSpot | Companies, contacts, products, calls, email activities, meetings, notes, tasks, tickets |
| Group two | One way, Airtable into HubSpot only | Deals, invoices, orders |
Read group two again. Deals sync in only one direction, and it is the direction most teams do not want.
The most common reason to connect Airtable to HubSpot is a base that needs to know a deal closed. That is the one direction this connector does not offer.
If your Airtable base is a delivery tracker, an onboarding queue, a fulfilment log or a project plan, the trigger you care about is a HubSpot deal reaching closed won. The native sync will happily take deals you create in Airtable and push them into HubSpot as deal records. It will not take a HubSpot deal and put it in your base. That single arrow direction explains a large share of the one-star reviews, and it explains why HubSpot's AI review summary reports that users say deal objects are not supported. They are supported. They are supported the other way round.
The two paths people conflate
As with several apps in this category, there are two entirely different mechanisms sharing one name, and comparing them is the fastest way to know which one you are actually being sold.
| HubSpot data sync | A HubSpot workflow action | |
|---|---|---|
| Shape | A standing sync with a matching key and per-object field mappings | A trigger and an action, fired once per enrolment |
| Direction | Two way on nine objects, inbound only on deals, invoices and orders | One way. Airtable's documentation states changes made in Airtable will not update back to HubSpot |
| Operations | Create and update, in both directions where mapped | Create only. A record appears in the base |
| Existing records | Historical data syncs on activation | Nothing. Only records that enrol from now on |
| Custom objects | Yes, on Hub Enterprise, without associations | Not applicable |
| Plan gate | Data Hub Starter to activate | A Hub Professional or Enterprise subscription for workflows |
Most people describing "the Airtable integration" mean the first. Most people who have been disappointed by "the Airtable integration" built the second, because a workflow action is the thing you reach for when you want a HubSpot deal to appear in Airtable, and it is the only native tool that does that direction at all.
How to Connect Airtable to HubSpot
The setup requirements are unusually specific, and two of them will make fields silently fail to appear rather than throw an error.
1. Confirm the Data Hub subscription before you configure anything
Activating a sync with Airtable requires Data Hub Starter. If you also need custom objects, that is Enterprise on Marketing Hub, Sales Hub, Service Hub, Data Hub or Content Hub. Checking this first is the difference between a half-hour setup and building a set of field mappings you cannot switch on.
2. Add an Email field in email format if you are syncing contacts
HubSpot documents this as required when syncing contact records, though not for company records. Note also that data sync by default only syncs contacts that have a valid email address, which you can disable, so a base full of leads captured without an email will look like a broken sync until you find that setting.
3. Add a Last modified time field and leave it on All editable fields
This is how the sync knows something changed, so it is not optional. HubSpot recommends giving it a recognisable name and hiding the field, and confirming the field type really is Last modified time. Scope it to All editable fields rather than a subset, or edits to unwatched fields will never trigger a sync.
4. Make every field you want mapped a Single line text field
HubSpot documents that text fields in Airtable should be formatted as a Single line text field to sync to a HubSpot property. This is the requirement that quietly reshapes a base, because Long text is where Airtable users keep the notes, the scoping detail and the context that a human actually wrote.
5. Choose the direction per object, deliberately
Data sync offers bidirectional, inbound only and outbound only. Pick per object rather than defaulting everything to two way, because a two-way mapping on a field that two teams both edit is how you build an argument between two systems that neither can win. The guide to data mapping covers how to decide which side owns which field.
6. Set the matching key with duplicates in mind
Companies match on something like name or domain, and HubSpot normalises for matching so capitalisation, special characters and punctuation are ignored. That helps, and it is also why two genuinely different subsidiaries with near-identical legal names will happily collapse into one record.
7. If you need associations, activate every sync before testing them
HubSpot documents that for some data sync apps, Airtable and Kintone specifically, and when syncing custom objects, all syncs must be activated in order for associations to be recognised. A contact sync alone will not produce company associations. Build the company sync first, then the contact sync, and map the field on the contact that holds the company information.
Where the Native HubSpot Airtable Integration Stops
None of this is a defect. It is all documented, which is exactly why configuration will not get you past it.
The limits that decide whether the native sync is enough
Associations are not maintained on custom object syncs. HubSpot states it directly and recommends mapping them manually. This is the structural limit, and it is the one that hurts most, because a custom object exists precisely to be associated with something.
Airtable's computed fields cannot be written to. Airtable's API documentation marks AI Text, Auto number, Button, Count, Created by, Created time, Formula, Last modified by, Last modified time, Lookup and Rollup as read only. HubSpot's field mapping documentation confirms the consequence: where the third-party app has read-only field restrictions, those fields map one way from HubSpot to the third-party app. So the derived layer of your base is a destination for nothing.
Deals, invoices and orders only travel one way. Airtable into HubSpot. There is no native path for a HubSpot deal to appear in a base, which is the single most requested direction in this pairing.
Long text does not map. The documentation points at Single line text. Everything a human typed at length, which in most bases is the genuinely valuable column, sits outside the mapped set.
Multi-value fields cannot be mapped to custom fields. HubSpot documents that fields with multiple values such as emails, phones and addresses, where the field can have multiple values with labels to distinguish them, cannot be mapped to custom fields. Secondary emails and alternate phone numbers are a common casualty.
Filters only govern the initial sync. HubSpot states that filters only limit which records initially sync, and that once records sync they continue to sync back and forth based on the property mapping. A filter is an opening condition, not a standing rule, so a record that later stops matching your filter keeps syncing.
It is near real time, not real time. After the initial sync, records sync within 10 minutes of a change. Fine for a CRM field. Not fine if something downstream is waiting on it to make a decision.
Nothing reconciles. The familiar one. There is no pass that compares the two sides and reports the difference, so the moment a mapping is wrong, a field is read only, or a record was created before the sync existed, the divergence is permanent and silent.
The Custom Object Privilege, and What It Actually Buys
This deserves its own section because it is the reason Airtable comes up in serious integration conversations at all, and because it is so easy to over-read.
HubSpot documents custom object sync as supported with exactly six apps: Airtable (tables), Kintone (tables), Microsoft Dynamics 365 (entities), Smartsheet (sheets), Snowflake and Zoho CRM (modules). Against a marketplace of well over a thousand apps, that is a rounding error, and Airtable is in it. If you have a custom object in HubSpot, this is one of the very few connectors that will look at it.
Three conditions come attached, and together they change the answer.
- 1
It requires Enterprise, not Data Hub Starter
Custom object sync is available with Marketing Hub Enterprise, Sales Hub Enterprise, Service Hub Enterprise, Data Hub Enterprise or Content Hub Enterprise. This is a materially different budget conversation from the Starter subscription that activates the sync in the first place, and it is the single most common reason a plan built around this feature stops at the pricing page.
- 2
The custom object must exist in HubSpot first
You create the object in HubSpot, then configure the sync. That ordering is fine, but it means the HubSpot data model leads and the base follows, which is the opposite of how these bases usually grow.
- 3
Associations will not be maintained
HubSpot's own words. The workaround it offers is to map associations manually. On a base of a few hundred records that is tedious. On a base of fifty thousand it is not a workaround, it is a second project, and it is one that has to be repeated every time new records arrive.
Put the two halves together and the shape of the limitation is clear from both sides at once. Coming from HubSpot, the custom object records cross and their associations do not. Coming from Airtable, the linked record fields are writable through the API but the fields that read across those links, the lookups and rollups and counts, are read only and cannot receive anything. In both directions, the nodes travel and the edges do not.
A relational database whose relationships do not survive the crossing has been converted into a spreadsheet in transit. HubSpot's listing is honest about this: it calls the Airtable side "records in a sheet."
What It Costs on Both Sides
The integration line item is zero, and that number is the least useful one available.
On the HubSpot side there are two thresholds. Data Hub Starter activates the sync and unlocks custom field mappings. Hub Enterprise unlocks custom objects. Nothing about Airtable changes those.
On the Airtable side, the plan you are on sets two separate ceilings, and integration people care about both.
The honest budgeting note is that Airtable's seat cost usually dwarfs the integration question, because collaborators are counted per person and bases spread. Before scoping any build here, count the seats you will need to keep in the workspace purely so the sync has somewhere to write.
HubSpot Airtable Integration: Native vs iPaaS vs Custom
Three routes, and they layer rather than compete. If the middle term needs defining, the guide to iPaaS covers the category.
Built by HubSpot, continuous, two way on nine objects, and it handles the matching and the field mappings for you. If your base is essentially a list of people or organisations and your fields are single line text and numbers, install it, spend an afternoon on the mappings, and build nothing. Start here every time.
The workflow action is the only native way to push from HubSpot into a base, and it is create only and one way. An iPaaS such as Make or Zapier gets you update logic and branching on top, at a per-operation subscription that grows with volume. Both are event based, so both leave you with no reconciliation and a duplicate problem the first time something is re-run.
Built against the Airtable Web API and the HubSpot API directly. Linked record fields are writable through that API even though lookups and rollups are not, so associations can genuinely be maintained in both directions. Computed values can be read from Airtable and written to real HubSpot properties. Deals can flow out as well as in. Failures retry, and a reconciliation pass catches the records that quietly never landed.
When to Build a Custom HubSpot Airtable Integration
Almost nobody should start here, and the native sync should usually stay switched on either way. The skill is noticing the point at which you have started working around the connector rather than with it.
Signs you have outgrown the native sync
Somebody re-links records by hand after every sync. This is the direct, visible symptom of associations not being maintained, and it is the clearest signal in the list. It also disguises itself as an admin chore rather than an integration gap, which is why it survives for years.
The number you need is calculated by a rollup. Total contract value across linked line items, days in stage, count of open tasks, a weighted score. Those live in read-only fields, so no sync can push them anywhere. A build reads the computed value and writes it to a HubSpot property that is genuinely writable.
You need closed-won deals in the base. The native sync does not do that direction, and a create-only workflow action produces a snapshot that immediately begins to age. If the base is a delivery tracker, this is your actual requirement and nothing native satisfies it.
The valuable column is Long text. Scoping notes, requirements, handover detail, research findings. If the reason the base exists is the prose in it, a sync scoped to single line text is solving a different problem than yours.
Custom objects are the point and Enterprise is not on the table.
The custom object path requires a Hub Enterprise subscription. A build against the API has no such gate, because the CRM API exposes custom objects on the plans that have them without a data sync entitlement in the middle.
Duplicates keep appearing and nobody can explain them. Normalised matching, filters that only govern the initial sync, and a create-only workflow path in parallel are three separate duplicate factories. Fixing that means owning the matching logic rather than configuring somebody else's.
Rate limits to know before you scope a build
This is where the Airtable pairing genuinely differs from everything else in this series, and the difference is worth understanding before anyone quotes you a timeline.
Now the part that makes this pairing unusual. In every other integration in this series, throughput is a licensing line item: NetSuite sells concurrency per SuiteCloud Plus licence, Acumatica puts requests per minute on the licence file, Docusign meters automated sends by plan. Buy more and the pipe gets wider.
Airtable does not sell that at all. Five requests per second per base is the number on the free plan and it is still the number on Enterprise Scale. What the higher plans buy is monthly quota, and Airtable is explicit that even the quota is not negotiable: API call limits are fixed per workspace plan and cannot be adjusted on a per-account basis.
Ask anyone quoting for this work what happens when the base holds 200,000 records. If the answer involves upgrading Airtable to make it faster, they have not built one of these.
What a Custom HubSpot Airtable Integration Costs
The honest comparison is not build versus free, because the native sync usually stays installed either way. It is build versus the running cost of the alternative: the Enterprise upgrade that unlocks a custom object sync which then drops your associations anyway, the iPaaS subscription that scales with record volume, and the standing hour every week that somebody spends re-linking records and copying rollup values into the CRM by hand.
A custom integration is a one-time build plus ongoing maintenance, priced by scope. Keeping a single flat table aligned is a small build. Maintaining an association graph across custom objects in both directions, reading computed values into writable CRM properties, pushing deals outward, retrying failures and reconciling nightly is a larger one. The cost teams underestimate is never the build. It is maintenance, because an Airtable base is the most-edited artefact in most companies. Somebody adds a field, renames a table, converts a single line text column to a select, and an unowned pipe drifts until neither side is trusted.
The cheapest moment to keep two systems agreeing is while they still agree. The most expensive is the quarter somebody discovers the base and the CRM have disagreed for a year and nobody can say which one was right.
That is why we productized it. StackTie builds the connection against the Airtable Web API and the HubSpot API directly for a fixed fee, then maintains it on a flat monthly retainer, so the records and the relationships between them both survive the crossing. The build fee and retainer are published on the pricing page rather than quoted per call.
Your records made it across. Did the relationships?
When linked records have to correspond to HubSpot associations, when the number you need is calculated by a rollup that no sync can write to, when closed-won deals have to reach the base rather than only leave it, or when a custom object sync is quietly dropping the graph you built the base around, that is a build. StackTie builds custom HubSpot Airtable integrations for a fixed fee and maintains them on a flat monthly retainer, alongside the native sync you already have. Live in 14 days or your money back. Book a free audit and we'll map exactly where your native option stops.
The Bottom Line
The HubSpot Airtable integration is better built and more privileged than most connectors in this category. HubSpot wrote it, certified it, and trusted Airtable with custom objects when it trusts almost nothing else. For a base that is essentially a list of people or companies described in single line text, it is the right answer and there is nothing to build.
What it cannot do is carry structure. Associations are not maintained on custom object syncs, by documentation rather than by accident. Airtable's formulas, rollups, lookups and counts are read only, so the layer that makes a base worth having is a layer no sync can write to. Deals move in only one direction, and it is not the one most teams need. Long text sits outside the mapped set. Add the three plan gates in three places and a throughput ceiling that is identical on every plan Airtable sells, and you have a clear enough picture to plan against.
The line is easy to state. If you need the rows, install the app. If you need the shape the rows are held in, that is different software, and no amount of field mapping turns one into the other.
