The short answer
A B2B data enrichment API adds missing contact or company fields to the records already held in your CRM, data warehouse, application or lead-routing workflow. A waterfall API checks more than one data source in a controlled sequence, validates the available results and returns one standardised response.
The objective is not to collect the largest possible response. It is to return the correct person, a usable work email, a valid phone number and enough company context to make the record operational.
Most businesses do not have a contact-volume problem. They have a usable-data problem.
A CRM may contain thousands of names with missing work emails, obsolete job titles, generic company phone numbers or no company domain. Inbound leads may arrive with only an email address. A product may need to identify a user’s company before onboarding. A sales workflow may have the correct account but no direct route to the decision-maker.
A data enrichment API solves this by accepting the identifiers you already have and returning the fields you need in a structured format. A waterfall enrichment API goes further: it searches multiple sources instead of allowing the coverage limits of one database to determine the result.
Definition: A waterfall data enrichment API sends a record through an ordered sequence of data sources until it finds a result that meets the required match and validation rules. The customer integrates one API and receives one normalised response.
What is a B2B data enrichment API?
A B2B data enrichment API connects an existing record to additional professional and company information. It does not require a user to search a separate sales platform and copy the result into another system. The enrichment happens inside the customer’s own workflow.
A request can begin with one strong identifier—such as a work email or LinkedIn profile—or with a combination of weaker identifiers such as name, company and domain. The API resolves the person and organisation, checks for available data and returns a structured record.
| Possible input | Possible output | Typical use case |
|---|---|---|
| First name + last name + company | Work email, phone, job title, seniority and company | Complete a partially populated CRM contact |
| Name + company domain | Matched professional profile and contact details | Enrich an outbound account list |
| Work email | Name, role, phone and company details | Enrich and route an inbound lead |
| LinkedIn profile URL | Work email, phone, job information and employer | Turn a known professional profile into an actionable record |
| Company website | Company identity, address, size, industry and contact channels | Account enrichment and company resolution |
The more reliable the input, the easier it is to avoid false positives. A full name and exact company domain usually creates a stronger match than a common name and company name alone. Your workflow should therefore send every relevant identifier it already holds.
How waterfall enrichment works
A single-source API asks one database for an answer. If that database has no record, the request ends. A waterfall keeps searching.
The sources are ordered according to the field required, geography, expected coverage, accuracy, price or a combination of those factors. As soon as an acceptable result is found, the waterfall can stop. If the result is incomplete, another source may be used to fill only the missing field.
Sequential waterfall
In a sequential waterfall, Source B is queried only when Source A produces no acceptable result. Source C is called only when both earlier sources fail. This controls cost and avoids paying several providers for the same contact.
The trade-off is latency. Each failed lookup adds another network request before the final response can be returned.
Parallel waterfall
In a parallel workflow, several sources are queried at the same time. This can reduce response time and makes it easier to compare conflicting results. It can also increase cost because multiple providers may return chargeable matches for the same record.
Hybrid waterfall
A hybrid workflow groups sources into tiers. Fast or low-cost sources run first. Higher-cost sources are used only if the first tier fails. This is often the practical choice when an application needs predictable response times but cannot justify calling every provider for every record.
| Model | Advantage | Trade-off | Best fit |
|---|---|---|---|
| Sequential | Strong control over cost | Slower when early sources miss | Batch CRM and database enrichment |
| Parallel | Fast and useful for comparison | Higher duplicate-query cost | Time-sensitive applications and validation |
| Hybrid | Balances latency, coverage and cost | Requires clearer routing rules | Production lead-routing and product workflows |
Inside the TargetWise waterfall
TargetWise is designed as a managed enrichment layer between the records a business already holds and the contact data it needs. The practical difference is consolidation: the customer submits the identifiers it has, TargetWise manages the enrichment process and the customer receives one standardised result instead of maintaining a collection of separate provider connections.
TargetWise’s published commercial model is equally important: customers pay when a valid email or phone match is returned, while unsuccessful searches are not charged. That aligns the invoice more closely with returned data than a subscription or per-search model.
During a POC, confirm what counts as a valid match, whether the source order changes by country or field, how conflicting values are handled and which freshness or confidence signals accompany the result. One integration removes operational complexity; it does not remove the buyer’s responsibility to define acceptance rules.
First match versus best match
A basic sequential waterfall stops when the first provider returns an answer. That is efficient only when “returned” and “acceptable” mean the same thing. A stale email, generic company number or result attached to the wrong employee can stop the search too early and prevent a better source from being considered.
The better design is to define the selection rule before enrichment begins. “Best” does not always mean the same thing: an instant lead-routing workflow may prioritise speed, while an enterprise database refresh may prioritise correct-person confidence and freshness.
Stops at the first returned value. Efficient, but vulnerable to stale or weak results.
Prioritises a lower-priced source. Useful only when the same quality threshold applies.
Compares identity, employer, validation and freshness signals before selection.
Accepts a result only when it meets the workflow’s required quality, cost and latency limits.
| Workflow | Suggested acceptance rule | Why |
|---|---|---|
| Inbound lead routing | Correct employer + valid work email within a response-time limit | A late result can harm conversion even if it is accurate. |
| Outbound list preparation | Correct person + current employer + field-level validation | Bounces and wrong-person matches damage sender reputation and productivity. |
| CRM refresh | Newer and better-supported than the value already stored | Enrichment should not overwrite more recent customer or sales-team data. |
| Embedded product | Customer-specific confidence, permitted-use and latency threshold | The accepted result becomes part of another company’s product experience. |
Why use a waterfall instead of one provider?
No B2B contact database has uniform coverage. A provider may perform well for US technology companies but poorly for private European businesses. Another may have strong work-email coverage but weak mobile coverage. A third may be useful for senior executives but add little for operational roles.
The value of the waterfall comes from the non-overlapping records found by later sources. If three providers return the same contacts, the waterfall adds cost without adding coverage. If each source is strong in a different segment, the combined result can materially improve the number of usable records.
- Higher coverage: a missed record can continue to the next source.
- Field-specific routing: email and mobile searches can use different source orders.
- Geographic routing: the provider sequence can change by country or region.
- Lower dependency risk: one provider’s outage or coverage gap does not stop the entire workflow.
- Controlled economics: expensive sources can be reserved for the records that cheaper sources could not resolve.
- One integration: the customer does not have to maintain several contracts, APIs and response formats.
Every additional source adds latency, commercial complexity and another opportunity for a false match. A good waterfall is measured by incremental valid matches and cost per usable record—not by the number of vendors connected to it.
Source A produces 520 accepted records. Source B is valuable only for the 130 valid records it adds after duplicates and rejected matches are removed. Source C should remain in the waterfall only if the value of its 45 incremental records exceeds its added cost, latency and governance burden.
What determines whether enrichment creates value?
A waterfall can increase coverage, but more sources do not automatically create better data. The result depends on four controls: the strength of the identifiers submitted, the amount of unique coverage added by each source, the validation standard applied to returned fields and the cost of reaching an accepted record.
Confirm the correct person and company using the strongest available identifiers.
Measure what each source adds after duplicates and overlaps are removed.
Reject emails, phones and attributes that do not meet the required quality threshold.
Apply CRM, compliance and commercial rules before a record enters a live workflow.
| Value driver | Question buyers should ask | Failure mode |
|---|---|---|
| Identity strength | Can the supplier prove it found the correct person at the correct company? | A plausible email is attached to the wrong individual. |
| Incremental coverage | How many valid records does each additional source contribute? | Several providers return the same contacts while cost and latency rise. |
| Field validation | What evidence is required before an email or mobile is accepted? | High reported coverage produces bounces, wrong numbers or generic switchboards. |
| Operational fit | Can the data be used safely within existing CRM and governance rules? | New values overwrite trusted data or enter workflows without provenance. |
| Unit economics | What is the cost per accepted, usable contact? | A low lookup price hides weak match quality and expensive unusable results. |
From submitted records to usable outcomes
Buyers should measure the full conversion chain. The headline match rate is only the first step. Results must belong to the correct person, pass field-level validation, comply with internal acceptance rules and create a measurable downstream outcome.
Measure cost per usable contact—not cost per lookup
The lowest advertised lookup price is not necessarily the lowest data cost. A provider becomes expensive when it charges for attempts, returns many duplicates, produces fields that fail validation or requires licences that are not used.
The key calculation is:
Cost per usable record = total enrichment cost ÷ records that pass your acceptance rules
TargetWise publishes volume-based pay-per-match pricing. Rates currently start at $0.20 per verified email and $0.35 per direct-dial phone, declining to $0.10 per email and $0.20 per phone at 35,000+ matches. If no requested data is found, the request is not charged. Enterprise arrangements may differ, so the current pricing page should remain the commercial source of record.
Illustrative calculation
Assume a file contains 1,000 contacts. The enrichment returns 700 chargeable verified work emails and 450 chargeable direct-dial numbers:
These are example volumes, not a promised match rate. Actual coverage depends on geography, role, company size, input quality and the fields requested.
Managed waterfall versus DIY versus one provider
The buying decision is not simply “which database has more contacts?” It is whether the organisation wants narrow coverage from one provider, full control over a multi-vendor stack or broader managed coverage through one enrichment service.
| Decision area | Single provider | DIY waterfall | Managed waterfall |
|---|---|---|---|
| Coverage model | Limited to one provider’s strengths and gaps | Several sources selected by the buyer | Multi-source enrichment behind one service |
| Contracts and DPAs | One supplier | Several supplier reviews and renewals | One customer-facing supplier relationship |
| Integration work | One schema and connection | Multiple schemas, authentication methods and release cycles | One schema and connection |
| Source ordering | Not applicable | Owned and maintained by the buyer | Managed within the service and tested against buyer requirements |
| Conflict and duplicate handling | Limited cross-source conflict | Designed and operated by the buyer | Consolidated before delivery, with customer acceptance rules |
| Monitoring and billing | Simple | Usage, outages and invoices reconciled across providers | Consolidated usage and commercial model |
| Control | Lowest | Highest | Shared: provider operates the stack; buyer sets the outcome |
| Best fit | Narrow, well-tested market with sufficient coverage | Large-scale teams with dedicated data engineering and vendor management | Teams that need broader coverage without owning a multi-vendor stack |
Managed-waterfall value = incremental accepted contacts + avoided operating cost − service premium
A managed service wins only if the additional usable coverage and avoided internal work exceed its price. A DIY stack remains rational when enrichment volume is very high, source-level control is strategically important and the business already has the engineering, procurement and privacy capacity to operate it.
Email and mobile enrichment need different rules
Work emails and mobile numbers should not be treated as interchangeable “contact data.” They have different sourcing, validation, decay and compliance risks.
| Decision | Work email | Mobile or direct dial |
|---|---|---|
| Basic validation | Syntax, domain, MX and mailbox checks where available | Country code, number format, carrier and line-type checks where available |
| Primary operational risk | Bounces and sender-reputation damage | Wrong person, wasted dial time and restricted calling |
| Useful acceptance rule | Correct person + current employer + deliverable work address | Correct person + callable business-purpose number + permitted geography |
| Recommended suppression | Bounces, opt-outs and role changes | Opt-outs, do-not-call lists and reassigned numbers where applicable |
Run separate waterfall orders for email and phone if the best source sequence differs. Stopping the entire workflow after finding an email may prevent a later source from returning a useful direct dial. Conversely, calling every mobile source when only email is required wastes money and increases data exposure.
Where a contact enrichment API fits
CRM enrichment
Enrich existing contacts on a schedule or when a record is created, edited or assigned. Use the response to fill gaps, flag stale data and route uncertain matches for review.
Inbound lead enrichment
A form may collect only a name, work email and company. The API can add role, phone and company context before lead scoring and assignment. Keep the enrichment outside the user-facing form path if response time would slow conversion.
Outbound list preparation
Submit a controlled account-and-contact list, retrieve the missing work emails or phones and write only accepted matches into the engagement workflow. This is more disciplined than purchasing a large static database that the team may never use.
Data warehouse and reverse ETL
Enrich records in the warehouse, preserve source and timestamp fields, then distribute approved values to the CRM, marketing platform and analytics layer. This prevents each system from creating a different version of the same contact.
Embedded product enrichment
A software provider can integrate enrichment into onboarding, lead research, recruiting, fraud review or another authorised business workflow. The customer sees the result inside the product rather than being redirected to a separate database.
AI-agent grounding
An AI agent should not guess a current email address or phone number from its training data. It can call an enrichment API at the point of need, receive structured data and stop when no verified result is available. The API response—not the model’s memory—becomes the operational input.
When a waterfall API is the wrong choice
Waterfall enrichment is not automatically the best architecture. A single provider may be sufficient when:
- Your target market is narrow and one tested source already provides high coverage.
- The value of an incremental match is lower than the added API and operational cost.
- Your workflow needs extremely low latency and cannot wait for sequential fallbacks.
- Your organisation cannot support the compliance review required for several underlying data sources.
- You need one provider’s proprietary field or methodology rather than broad contact coverage.
- Your volume is too small for the engineering and measurement effort to be worthwhile.
Test the waterfall against a representative sample before committing. Measure the first source, the incremental matches from every later source, validation outcomes, latency and total cost. Remove any source that contributes too few accepted records to justify its cost and complexity.
Six ways waterfall enrichment fails
Most waterfall problems do not come from a broken connection. They come from rules that optimise the wrong outcome. A workflow can report a high match rate while producing stale contacts, duplicate costs, slow responses or damage to trusted CRM data.
These controls should be measurable. For example, “deduplicated” should mean that two providers cannot produce two accepted charges for the same person and field; “current employer” should have a defined verification rule; and “fast enough” should be expressed as median and 95th-percentile response time.
How to evaluate a data enrichment API
A polished demo is not enough. Run a proof of concept using records that reflect your actual market mix and operational difficulty.
| Evaluation area | Question to ask | Evidence to request |
|---|---|---|
| Identity accuracy | How does the API avoid matching the wrong person or company? | Field-level match logic, confidence rules and test results |
| Coverage | What is the incremental match rate by country, seniority and company size? | Results from your own blinded sample |
| Validation | What makes an email or phone result chargeable and usable? | Definitions, validation states and replacement policy |
| Economics | Do failed attempts, duplicates or partial results consume credits? | Invoice simulation based on the POC output |
| Integration | Can the service support the required volume, speed and workflow? | POC results, service commitments and an operating-model review |
| Compliance | Can the provider explain sourcing, permitted use and rights handling? | Contract terms, DPA, privacy information and suppression process |
| Operations | Can results be traced, measured and corrected? | Usage metrics, support process and audit fields |
Require provenance and freshness fields
A returned value is easier to govern when the response records when it was retrieved or last validated, which input produced the match and which confidence or validation state was applied. Without that context, a CRM user cannot distinguish a recently verified work email from an older value that merely passed formatting checks.
For enterprise workflows, agree which provenance fields will be retained in your systems, how long enriched values remain acceptable and what triggers re-enrichment. The answer may differ by field: job title, employer, work email and mobile number do not decay at the same rate.
Compliance is part of the integration
A data enrichment API is a processing tool. It does not decide whether a specific outreach, profiling or product use is lawful. The customer remains responsible for its purpose, lawful basis, notices, retention, security, suppression and communications rules.
Before deploying contact enrichment, document:
- The purpose for which each field is collected
- The lawful basis relied upon in each relevant jurisdiction
- Who can access the enriched data
- How long the data will be retained
- How opt-outs, objections, corrections and deletion requests will be processed
- Which systems receive the data after enrichment
- Which phone and email suppression lists must be applied before outreach
- How the provider’s contractual permissions align with your intended use
Ask legal or privacy counsel to review the actual workflow and countries involved. “B2B data” is not a blanket exemption from privacy and electronic-communications law.
The POC scorecard buyers should use
A useful POC ends with one shared scorecard, not separate conclusions from sales, engineering and procurement. Test a blinded sample that represents the countries, seniorities, company sizes and input quality found in production.
Accepted matches divided by all returned matches, verified against the intended person and employer.
New accepted emails or phones added by each waterfall stage after duplicates are removed.
Total cost divided separately by accepted emails and accepted direct-dial phone numbers.
Median and 95th-percentile response time, including records that reach later waterfall stages.
Email bounce, phone connection, qualified-meeting and conversion outcomes—not returned fields alone.
Permitted use, provenance, retention, suppression, deletion and audit requirements confirmed before launch.
Buyer checklist
- Define the business outcome and the exact fields required.
- Choose the strongest input identifiers available in each workflow.
- Test a representative, blinded sample before production use.
- Set person- and company-match acceptance rules.
- Separate full matches, partial matches and no-match outcomes.
- Agree the required service volume, response speed and support model.
- Define field-level CRM merge and overwrite rules.
- Store the enrichment source and timestamp where appropriate.
- Measure cost per accepted email and phone—not only request volume.
- Monitor bounces, connection rates and downstream conversion.
- Apply retention, suppression, opt-out and access controls.
- Review performance by country, seniority, company size and input type.
Enrich B2B contacts through one API
Send the identifiers you already hold and return available work emails, direct-dial phone numbers and company context through a structured response. Pay for successful matches, not unsuccessful searches.
Frequently asked questions
1. What is a data enrichment API?
A data enrichment API adds missing or updated information to an existing record. For B2B contacts, it can accept identifiers such as a name, company, domain, work email or LinkedIn URL and return available professional contact and company fields in a structured format.
2. What is a waterfall enrichment API?
A waterfall enrichment API checks multiple data sources in an ordered workflow. When the first source cannot return an acceptable result, the record moves to the next source. The customer uses one integration and receives one normalised response.
3. What information can I use to enrich a B2B contact?
Common inputs include first name, last name, company name, company domain, work email and LinkedIn profile URL. Providing more than one reliable identifier generally makes it easier to resolve the correct person and employer.
4. What data can a contact enrichment API return?
Depending on the input and data availability, a contact enrichment API can return a work email, direct-dial or business phone number, full name, job title, seniority, department, company name, company identifier and LinkedIn profile. No provider can return every field for every contact.
5. How is a waterfall API different from a contact database?
A contact database is usually searched through the provider’s platform and often uses one provider’s dataset. A waterfall API enriches records inside your own system and can search several sources behind one endpoint. The two models may coexist, but the API is better suited to automated and embedded workflows.
6. Does waterfall enrichment guarantee a higher match rate?
No. It improves coverage only when later sources find valid records that earlier sources missed. If the sources overlap heavily, the waterfall may add cost and latency without a meaningful lift. Test every source’s incremental contribution using your own sample.
7. How much does the TargetWise enrichment API cost?
TargetWise currently publishes volume-based pricing starting at $0.20 per verified email and $0.35 per direct-dial phone, declining to $0.10 per email and $0.20 per phone at 35,000+ matches. The requested field is not charged when no valid match is found. Check the TargetWise pricing page for current rates and enterprise terms.
8. Can I use a data enrichment API with a CRM?
Yes. A CRM can call the API when a record is created, edited, assigned or included in a scheduled enrichment job. Define field-level merge rules so that enrichment does not overwrite trusted customer-provided or recently verified data.
9. Is B2B contact enrichment GDPR compliant?
Compliance depends on the customer’s purpose, lawful basis, transparency, retention, security, suppression and communications practices—not the API alone. Businesses should assess their specific workflow and jurisdictions and obtain legal advice where necessary.
10. How should I test a waterfall data enrichment API?
Use a representative blinded sample and measure correct-person matches, verified emails, callable phone numbers, incremental results from later sources, no-match rate, latency, cost per accepted record and downstream outcomes. Do not evaluate providers only on the total number of fields returned.
