Contact Enrichment API vs Lead Search API: Choosing the Right Endpoint for Every Outbound Workflow

Most teams that get frustrated with a B2B data API are not frustrated with the data. They are frustrated because they called the wrong endpoint. They sent a list of company domains to a search endpoint and got nothing useful back. Or they sent a set of ICP filters to an enrichment endpoint and wondered why it returned a single contact instead of a list of 4,000.

The contact enrichment API vs lead search API question is not a feature comparison. It is a workflow question. Each endpoint answers a different question, and the question you are asking at a given stage of your outbound pipeline determines which one you should call.

Here is the distinction in one line:

A lead search API takes filters and returns a list. A contact enrichment API takes a known contact or company and returns richer fields about it.

Search is how you find people you do not have. Enrichment is how you complete people you already have. Everything else in this article is a consequence of that split — the input shapes, the output shapes, the credit economics, the failure modes, and the way you chain the two together into a single pipeline.

If you want the parent overview of both endpoints before going deeper, the B2B leads API page covers the full surface area. This article focuses on the decision layer: which endpoint to call, when, and why.

Enrichment is a lookup operation. It requires an anchor — something that identifies a specific person or company — and it returns additional attributes attached to that anchor.

• A work email address
• A LinkedIn profile URL
• A name plus a company domain
• A company domain on its own (firmographic enrichment)
• A CRM record ID mapped to one of the above

• Verified or corrected email address
• Direct dial or mobile phone, where available
• Current job title and normalized seniority level
• Department and function classification
• Company name, domain, employee count, industry, headquarters location
• LinkedIn URL and social handles

The important property of enrichment is that it is deterministic in shape. You send one record, you get one record back. There is no pagination, no result set, no "how many matches are there" question. If the anchor is valid and the record exists in the provider's coverage, you get fields. If it does not, you get a miss.

• CRM cleanup. You have 12,000 records with stale titles and missing phone numbers. Enrichment fixes them in place.
• Inbound lead scoring. A form fill gives you an email and nothing else. Enrichment turns it into a scored, routed, assignable lead with firmographics attached.
• Product-led growth signals. A user signs up with a personal email. Enrichment resolves the company domain so you can route to sales.
• Event and webinar follow-up. You have a badge scan list. Enrichment fills in the gaps before sequencing.
• ABM account completion. You know the target account. Enrichment finds and completes the buying committee inside it.

The common thread: you already have a record, and you need it to be more complete. The contact enrichment API is built for exactly this pattern, including the LinkedIn-URL-first flow that most RevOps teams end up standardizing on.

Search is a discovery operation. It takes a description of who you want and returns a set of people who match. There is no anchor record — the filters are the input.

• Job title or role keywords, plus seniority bands
• Industry, sub-industry, or SIC/NAICS classification
• Employee count or revenue range
• Geography — country, region, metro
• Technologies used, funding stage, or growth signals
• Department and function
• Exclusions — competitors, existing customers, suppressed domains

• A paginated list of matching contacts
• Per-contact fields: name, title, company, domain, location, and often email
• A total match count for the query
• Cursor or page tokens for retrieving the next slice

The important property of search is that it is non-deterministic in size. The same query can return 40 records or 40,000. That is why preview and count endpoints matter so much — you want to know the size of the result set before you start paying to retrieve it.

• Net-new list building. You have an ICP and no list. Search produces the list.
• Market sizing. You want to know how many VP Sales at 50–200 person SaaS companies in North America actually exist in the dataset.
• Territory planning. You need to split a market by geography or segment and assign owners.
• Lookalike expansion. You have 30 great customers. Search finds the 3,000 companies that look like them.
• Recurring pipeline generation. A scheduled job pulls new matches every week. This is the core pattern behind a lead generation API workflow.

The common thread: you do not have the records yet, and you need a set that matches criteria.

If you are pulling large result sets from the search side, the mechanics of cursors, page sizes, and dedup across pages are covered in the B2B leads API search filters reference. Getting pagination wrong is the single most expensive mistake in a search-heavy pipeline, and the filter design that drives it deserves the same attention.

Map your pipeline stage to the endpoint before you write any code. This table is the one most teams should pin somewhere visible.

Notice how many rows say "enrichment" for stages that happen after a record enters your system, and "search" for stages that happen before. That is the whole framework. Search is upstream of your database. Enrichment is downstream of it.

For broader context on how these stages fit into a sales motion, HubSpot's prospecting guide walks through the sequencing logic that search and enrichment ultimately feed.

In practice, mature outbound pipelines use both endpoints. Here are the three patterns that show up most often, in order of how common they are.

The default. You run a search query against your ICP, get back a list of contacts with partial data, then enrich the subset that matters — usually the ones you are about to sequence.

1. Define ICP filters and preview the match count before spending credits.
2. Run the search and page through results, deduping against your suppression list.
3. Score or segment the returned records.
4. Enrich only the records entering an active sequence.
5. Write enriched fields back to the CRM or export destination.

The value of this pattern is that you avoid enriching records you will never contact. If your search returns 8,000 matches and you will only sequence 600 this month, enriching all 8,000 is pure waste.

You start from accounts you already care about — closed-won customers, target ABM accounts, or a partner list — and use enrichment to resolve them into a clean set of domains and firmographics. Then you run search queries built from those resolved attributes to find similar accounts or additional buying-committee members.

1. Enrich your seed account list to normalize domains, industries, and size bands.
2. Cluster the enriched accounts into segments with shared attributes.
3. Build search queries from each cluster's dominant attributes.
4. Preview counts, then pull the lists that clear your volume threshold.

This is the pattern behind most lookalike and account-expansion programs, and it depends entirely on enrichment output being clean enough to build filters from. Field normalization matters here — the contact enrichment API field mapping guide covers how to keep industry, seniority, and size values consistent enough to feed back into search filters.

You have a mixed inbound stream: some records arrive with a full set of fields, some arrive with almost nothing. Instead of running everything through the same path, you route by confidence.

• High confidence (work email + company domain + title present): skip enrichment, go straight to scoring and routing.
• Medium confidence (work email only): enrich to fill title, seniority, and firmographics.
• Low confidence (personal email, no domain): enrich to resolve the company, then decide whether to route to sales or to a nurture track.
• No match after enrichment: route to a manual review queue rather than burning further credits on retries.

This pattern is the most credit-efficient of the three because it never pays for data you already have. It does require you to define confidence tiers explicitly, which is a one-time design decision that pays off indefinitely.

Credits are the operational constraint that turns an architectural decision into a budget decision. The two endpoints consume credits differently, and mixing them without a plan is how teams end up with a mid-month overage.

Two habits keep credit spend under control regardless of which endpoint dominates your pipeline.

First, preview before you pull. A count or preview call tells you how large a result set is before you commit to retrieving it. If a filter combination returns 90,000 records and your monthly budget supports 5,000, you need to tighten the filters — not discover the problem after the fact. The preview leads endpoint exists for exactly this step: validate a segment's size and coverage before any credits are spent on retrieval.

Second, enrich late. Enrichment is most valuable immediately before a record enters an active sequence or gets written to a system that depends on the enriched fields. Enriching at capture time means you pay for records that may sit untouched for months and go stale before anyone contacts them.

Before you wire either endpoint into production, walk this list. It is short, and every item on it has cost a team real credits at some point.

1. Define the ICP before writing filters. Vague criteria produce vague result sets and unpredictable credit spend.
2. Preview counts before running a full search. Validate that the segment exists at a useful size before retrieving it.
3. Enrich only records with a valid anchor. No email, no LinkedIn URL, no name-plus-domain means no enrichment call.
4. Dedup before export, not after. Duplicate records in a search result set are duplicate credits.
5. Handle pagination explicitly. Track cursors, cap page sizes, and stop when the result set is exhausted rather than looping blindly.
6. Log credit spend per stage. Attribute cost to search, enrichment, and retries separately so you can see which stage is actually expensive.
7. Set a retry policy. One retry on a transient failure is reasonable. Three retries on a record that does not exist is a budget leak.
8. Define a no-match path. Decide in advance what happens to records that fail enrichment, so they do not silently re-enter the queue.

Calling enrichment without a known identifier. Enrichment is not a search engine. If you send a job title and a city, you are asking the wrong endpoint for the wrong thing. Send an anchor.

Calling search without meaningful filters. A search with one broad filter returns a result set too large to use and too expensive to retrieve. Narrow with two or three intersecting criteria before you pull.

Double-charging on dedup. If you pull the same segment weekly and do not dedup against previously retrieved records, you pay for the same contacts repeatedly. Maintain a suppression set of already-retrieved identifiers.

Ignoring pagination limits. Search endpoints cap how much you can retrieve per call. Teams that assume a single call returns everything end up with truncated lists and no error to tell them so.

Enriching before segmenting. If you enrich an entire raw list and then narrow it down, you paid for records you discarded. Segment first, enrich second.

Treating enrichment output as final. Enrichment returns the best available value at the time of the call. Titles change, people move. Build a refresh cadence rather than assuming a one-time enrichment is permanent.

Once the endpoint decision is made, the implementation details determine whether the pipeline is maintainable.

Enrichment responses need to be mapped into your CRM's schema, and the mapping has to handle missing values, casing differences, and title variations. Normalizing seniority into a fixed set of bands — rather than storing raw title strings — is what makes downstream filtering and routing reliable. This is the same normalization discipline that makes enrichment field mapping work across multiple data sources.

Single-record enrichment is usually fine as a synchronous call inside a form handler or a webhook. Bulk enrichment and large search retrievals should be asynchronous jobs with a queue, so a slow response does not block a user-facing request.

Respect the documented rate limits and batch where the API supports it. Batching reduces request overhead but increases the blast radius of a failed call — so batch in sizes you can retry cheaply.

Decide which fields enrichment is allowed to overwrite. A common rule: enrichment can fill empty fields freely, but can only overwrite populated fields when the existing value is older than a defined staleness threshold. This prevents a fresh manual update from being clobbered by an automated refresh.

Search and enrichment sit at different points in the lead lifecycle, and the lifecycle model should reflect that. Salesforce's Lead Management implementation guide is a useful reference for structuring the stages that enrichment and search feed into, particularly around when a record becomes actionable versus merely captured. For the broader pipeline view, Salesforce's B2B lead generation guide maps those stages onto a full funnel.

The rule is simple enough to remember without a diagram:

• Search when you need a list. You have criteria and no records.
• Enrich when you already have a contact. You have a record and need it complete.

Everything else — credit budgeting, pagination handling, dedup strategy, field mapping — is downstream of getting that first decision right. Teams that route correctly spend less, ship faster, and stop blaming the data for problems that were actually architectural.

If your pipeline is mostly post-capture — CRM hygiene, inbound routing, ABM completion, product-led company resolution — start with the contact enrichment API and design your confidence tiers around it. If you are building net-new pipeline on a schedule, pair it with the search side and let enrichment run only on the records that clear your sequencing threshold. That combination is what a durable lead generation API workflow actually looks like in production.

Pick the endpoint that matches the stage. Then measure credits per stage, not credits per month — that is the number that tells you whether the architecture is working.