Enrichment used to be a budget question. You bought a pack of credits, one credit enriched one record, the credits expired at the end of the month, and somebody had to decide which contacts were worth spending them on.
That question has mostly gone away. HubSpot's standard data enrichment does not consume credits, which means the sensible default is now to turn it on for everything and stop thinking about it. Which is exactly what a lot of teams did, and it is why the more common question in 2026 is a different one: enrichment is free, it is switched on, and the data is still wrong. Where did it actually go?
The answer is that enrichment is a narrower feature than its name suggests. It fills a fixed list of firmographic and identity fields, on records that already carry a usable identifier, only where the field is currently blank. Every one of those three clauses excludes something, and what they exclude between them is most of what makes CRM data useful. This guide covers what the feature genuinely does, the three reasons it silently skips records, and the point where the remaining gap stops being a settings problem. If you are earlier than this and mapping the wider landscape, the guide to HubSpot integrations covers what connects to what first.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
What Is HubSpot Data Enrichment?
HubSpot data enrichment automatically populates contact and company properties by matching your records against HubSpot's commercial dataset, third-party providers and public web sources.
It works from two inputs and only two. For contacts, it uses first name, last name and work email. For companies, it uses the domain name. Those are the join keys. Everything the feature can do downstream depends on one of them resolving to something in the dataset, which is why so much of the behaviour that confuses people traces back to a record that never matched in the first place.
This is the product that was Clearbit. HubSpot announced the acquisition on 1 November 2023, reportedly for around $150 million, rebranded it Breeze Intelligence at INBOUND 2024, and then closed the standalone business down: free Clearbit tools discontinued on 30 April 2025, the Enrichment, Prospector and Logo APIs deprecated, the Logo API switched off in December 2025. In June 2025 the separate Breeze Intelligence credit packs folded into general HubSpot Credits.
That history matters for one practical reason. Clearbit used to be an API you could call from anywhere in your stack. The same data is now a feature inside a CRM. If you were enriching records in a product database, a warehouse or an internal tool, that route closed, and the enrichment now happens in HubSpot or it does not happen at all.
What HubSpot Enrichment Actually Fills
The property list is public and finite, and reading it carefully is the fastest way to calibrate expectations.
On contacts, HubSpot enrichment fills twelve properties: first name, last name, job title, employment role, employment sub role, employment seniority, LinkedIn URL, city, state or region, state or region code, country and country code. Two more properties exist to track enrichment opt-out and the timestamp of that opt-out.
On companies, it fills around thirty, including annual revenue, revenue range, number of employees, employee range, industry, company domain name, website URL, year founded, web technologies, and the LinkedIn, Facebook and X handles.
Now read the contact list again for what is not on it.
The company side is considerably stronger than the contact side, which follows from the join key. A domain is a clean, unique, publicly observable identifier and firmographics about a company are largely a matter of public record. A person's role inside that company is neither stable nor public, and the dataset reflects that.
So the honest framing is that this is a company enrichment feature with a contact side attached. If your segmentation runs on industry, employee count and revenue band, it will do real work. If your segmentation runs on persona and seniority, expect gaps.
What It Costs Now That Enrichment Is Free
Standard data enrichment does not consume HubSpot Credits. That is a genuine change in the economics and it is worth being explicit about what it does and does not cover.
Smart properties are the part that still costs money, and they are a different mechanism worth understanding separately. Where enrichment matches a record against a dataset, a smart property runs HubSpot's data agent against sources you define, such as web research, the company's own website, activity transcripts or existing property values, and writes back whatever it concludes. That is a research task rather than a lookup, and it is priced accordingly.
Two details catch people out. A smart property consumes credits even when it does not fill a value, so a prompt with a poor hit rate burns budget producing empty fields. And prompts that reference LinkedIn are filtered out and may return nothing, which quietly rules out a category of prompt that seems obvious to write. Smart properties also cannot carry validation rules and cannot be marked as sensitive data.
On credits generally: they expire at the end of each usage period and do not roll over, and pay-as-you-go overage is billed monthly in arrears in increments of ten credits, rounding down. Allowances vary by your highest subscription tier.
The interesting consequence of free enrichment is that the constraint moved. It used to be how many records you could afford to enrich. Now it is how many of your records can be enriched at all.
How to Enrich Contacts and Companies in HubSpot
Run these in order. The first step is the one everybody skips and it is the one that tells you whether the rest is worth doing.
- 1
Run a data test before you write anything
The data test samples up to 100 records from an index page or a segment and reports two numbers: your match rate, meaning the percentage of records eligible for enrichment, and per-property coverage, meaning which specific fields would actually get filled. Testing is available to all users even though running enrichment needs a paid tier. Do this first on a segment you care about rather than on the whole database, because match rate varies enormously between a list of enterprise accounts and a list of self-serve signups, and the average across both tells you nothing useful about either.
- 2
Enrich manually on a scoped set
From a contact or company index page you can enrich up to 100 records at a time, and manual enrichment is the only mode that lets you choose to overwrite existing values rather than only filling blanks. Use this deliberately on a defined segment. Segments, workflows and imports allow larger batches than the 100-record index page ceiling if you need volume.
- 3
Turn on automatic enrichment
Automatic enrichment is off by default and requires Super Admin permissions to configure. Once on, it enriches new records continuously as they arrive, filling blanks only. This is the setting most portals should have enabled and many have never touched, because the default is off and nobody goes looking for a settings page for a feature they assume is already running.
- 4
Watch enrichment coverage in the data quality overview
The data quality overview has a data enrichment tab reporting match rate and per-property enrichment coverage as percentages, alongside duplicate volume, formatting issues and property insights. It needs Super Admin or explicit data quality tools access. Treat the coverage percentage as the real health metric, not the count of records enriched, because the second number always goes up and only the first one tells you whether the gap is closing.
Where HubSpot Data Enrichment Stops
Three exclusions do most of the damage, and they compound rather than sitting independently.
Records without a business identifier are skipped entirely
HubSpot will not enrich contacts with personal email addresses. Gmail, Yahoo and temporary providers are excluded, and a company record without a domain name has nothing to match on. This is not a coverage gap in the dataset, it is a structural precondition. For a self-serve or product-led business where a meaningful share of signups arrive on a personal address, the feature simply does not apply to that population, and that population is usually the one with the least data attached in the first place.
Automatic enrichment only fills blanks, so it cannot resolve a conflict
If a property already has a value, automatic enrichment leaves it alone. That is the correct default, because overwriting a human's deliberate entry with a vendor's guess would be worse. But it means enrichment is structurally incapable of fixing wrong data. A company whose employee count was set to 50 during a 2022 import stays at 50 forever, and the enrichment coverage report will count that property as covered. Populated is not the same as correct, and only one of the two is measured.
No vendor has your first-party data
This is the largest gap and the least discussed, because it is not a HubSpot limitation so much as a category limitation. Product usage, billing status, plan tier, contract value, open ticket count, implementation stage, last login, feature adoption: none of that exists in any enrichment dataset anywhere, because it only exists in your systems. And it is generally the data that decides things. Routing, renewal risk, expansion signals and health scores all run on first-party fields, and enrichment does not touch any of them.
The compounding is the part worth sitting with. The records excluded for having a personal email are disproportionately the self-serve signups, who are also the ones whose product usage would tell you the most, which is exactly the data enrichment does not carry. So the population the feature cannot reach and the data the feature cannot supply overlap almost perfectly.
The Four Decisions Nobody Makes Until the Data Is Wrong
Once more than one thing writes to a property, you have a data governance problem whether or not anyone has named it. These four decisions are cheap to make up front and expensive to make retroactively, because by then there is history to reconcile.
Decide these before adding a second source
Source of truth, per field, not per system. The instinct is to declare that HubSpot owns contacts and the billing system owns invoices. That resolution is too coarse. The real question is who owns employee count, and the answer might be the enrichment dataset for prospects and the signed contract for customers, which means ownership changes when lifecycle stage changes. Write it down at field level or it will be decided implicitly by whichever integration ran last.
Overwrite policy, including the empty case. Fill blanks only is the safe default and it is also how data goes stale. Decide which fields are allowed to be overwritten by a fresher source and which are sacred. Then decide the harder one: if the new source returns nothing, does the old value stay or get cleared? Most systems silently keep the old value, which is usually right and occasionally very wrong.
Refresh trigger, not refresh schedule. Automatic enrichment fires on record creation. Almost nothing re-enriches on a meaningful event afterwards. Companies get acquired, people change jobs, headcount doubles. Decide what should trigger a refresh, such as a deal reaching a stage, a renewal window opening, or a contact going quiet, rather than assuming a nightly job you have not built is running.
Provenance, so a wrong value can be traced. When leadership asks why the ARR number in a board deck disagrees with the finance system, the answer needs to name a source and a date. HubSpot keeps property history, but if three systems write to the same field through the same private app, the history says the private app did it, which is not an answer. Stamp the source on the record if it matters.
The data mapping guide goes deeper on how field-level ownership gets written down in practice, and building a customer 360 covers what happens when the same entity exists in five systems at once.
Breeze Intelligence vs Third-Party Enrichment vs a Custom Pipeline
These are frequently compared as though they were three prices for one thing. They are three different jobs, and most mature portals end up running at least two of them.
Free, bundled, and it runs automatically on records as they arrive. Fills industry, revenue, employee count, location and job title on anything with a business email or a domain. There is no reason not to have this on. Turn it on, run a data test to learn your real match rate, and treat whatever it covers as the baseline everything else is measured against. The mistake is buying something else before establishing this number.
ZoomInfo, Apollo, Cognism and the rest sell a different product: contact discovery with phone numbers and direct dials attached, priced per seat or per credit. HubSpot does not sell this and its property list makes that explicit. If outbound needs dials, this is a real purchase rather than a redundant one. Just be clear that you are now running two sources into one portal, which makes the four decisions above mandatory rather than optional.
Product usage, billing state, ticket volume, contract value and implementation stage are not for sale. Getting them onto the CRM record on a schedule, with declared precedence against the vendor fields already there and a trace of what wrote what, is an integration rather than a subscription. This is also the only option that can arbitrate between two enrichment vendors rather than letting whichever ran last win.
Worth noting where the native automation layer sits in this. HubSpot's own sync and automation tooling handles a good deal of the movement between apps, and the Operations Hub guide covers where that stops. Enrichment sits alongside it rather than inside it: Operations Hub moves data you already have somewhere, enrichment adds data you do not have at all, and neither one decides which value wins.
When Enrichment Becomes a Build
The transition is not usually dramatic. It arrives as a question somebody cannot answer.
Signals the settings page has run out
Two sources write the same field and nobody declared a winner. The symptom is a value that changes back and forth on a record's property history, or a report whose number moves without anyone editing anything. Neither vendor will resolve this because neither knows the other exists. Precedence has to live in something you control.
The field that routes leads is a field enrichment does not carry. Routing on industry and employee count is well served natively. Routing on plan tier, usage in the last 30 days, or whether the account has an open critical ticket needs those values on the record, and they only exist in your product, your billing system and your helpdesk. The Intercom integration guide is a worked example of how much support data does not survive the trip.
Enrichment needs to run on an event rather than on arrival. Automatic enrichment fires when a record is created. If you need a company re-checked when a renewal window opens, or a contact re-verified after six months of silence, that is a scheduled or triggered job against the API and nothing in the settings page will do it.
Your excluded population is the one that matters. If half your signups arrive on personal email addresses and those signups are your growth motion, the free layer covers the half you worry about least. Identity resolution for those records, matching a personal address to an account through product data rather than through a dataset, is a build by definition.
Somebody needs an audit trail. Finance, security and anyone preparing a board number eventually asks where a value came from. A pipeline can stamp source and timestamp per field. A vendor toggle cannot.
What the API side actually constrains
If you are scoping a pipeline, three limits shape the design more than anything else, and it is worth knowing them before someone promises a real-time sync.
Private app rate limits run at 100 requests per 10 seconds and 250,000 per day on Free and Starter, and 190 per 10 seconds with 625,000 per day on Professional and 1,000,000 per day on Enterprise. The API Limit Increase add-on raises this to 250 per 10 seconds, purchasable at most twice. Burst limits apply per app, but the daily cap is shared across every app on the account, so a new pipeline is drawing from the same budget as every existing integration.
The CRM Search API is metered far tighter, at 5 requests per second at the account level, shared by everything running under it. Any pipeline whose design is "search for records needing enrichment, then update them" will hit this before it hits anything else. A single query is also capped at 10,000 total results, so a backfill across a large database has to be segmented, usually by creation date range.
Batch endpoints take 100 records per call, which is the single biggest lever available. A pipeline that writes one record per request and one that batches is the same pipeline with a hundredfold difference in headroom, and the difference between one that works at your current volume and one that works at three times it.
What a Custom Enrichment Pipeline Costs
Scope is what moves the number, and enrichment work sorts into a fairly predictable range.
A pipeline that pulls first-party fields from one system onto HubSpot records on a schedule, with field-level precedence and batched writes, is a contained build. Add a second source with conflict resolution between them, or identity resolution for records without a business domain, and it grows. Add a backfill across a large database and the work is mostly in segmentation and rate budgeting rather than in the logic.
StackTie builds these at a flat $12,000, or $7,500 for our first three founding clients in exchange for a named case study, with 50% up front and the balance on go-live. Live in 14 days or the deposit comes back. Maintenance is $2,000 a month starting 30 days after go-live, which for an enrichment pipeline is the part that matters most, because vendor datasets change their shape, API limits change, and a pipeline nobody watches quietly stops writing and nothing in the CRM says so.
For a wider view of what integration work costs and how the pricing models differ across agencies, freelancers and specialists, the custom HubSpot integration guide covers the ranges, and who should build your integration covers picking between the options.
Enrichment on, and the fields that matter still empty?
StackTie builds the layer HubSpot enrichment cannot: your product usage, billing state and support data on the CRM record, with a declared winner for every field two systems both write to and a trace of what changed when. The scoping call is free and ends in a written field map, including the parts we would leave to the native layer because it already does them for nothing. If a build is the answer, live in 14 days or your money back.
The Bottom Line
HubSpot data enrichment became free, which is unambiguously good and means it should be on in every portal. Turn on automatic enrichment, run a data test on the segments you care about, and read the match rate rather than the record count.
Then be clear about what you have bought. Twelve contact properties and around thirty company properties, filled only where blank, only on records carrying a business email or a domain. No phone numbers. No conflict resolution, so anything already wrong stays wrong. No coverage at all of the self-serve population arriving on personal addresses. And nothing whatsoever from your own product, billing or support systems, because no vendor has that data to sell.
Which leaves a reasonably clean division of labour. The free layer handles firmographics, and it handles them well enough that paying for that specific job is usually a mistake. A contact data provider handles reaching people you cannot currently reach, if outbound needs it. And everything that actually decides something, the usage, the billing state, the tickets, the contract, is first-party, which means it arrives on the record because somebody built the thing that puts it there or it does not arrive at all.
The trap is spending a quarter tuning the free layer hoping it will eventually cover the third category. It will not, and the property list says so plainly enough if you read it before rather than after.
