Lead Enrichment API: How to Pick One That Actually Works

TL;DR

• A lead enrichment API turns a thin identifier (an email, a domain, a name plus company) into a full contact or company record through an HTTP request, so your CRM fills itself instead of your SDRs doing it by hand.
• The only two numbers that matter are match rate on your actual list and cost per matched record. Vendor-quoted coverage numbers are measured on their own sample, not yours.
• Credit models differ more than headline prices. Some vendors charge for misses, some charge per enriched field, some bundle verification and some bill it separately.
• Budget range in 2026 runs roughly $0.01 to $0.25 per enriched contact depending on volume, waterfall depth, and whether phone numbers are included.
• Run a 500-row bake-off before you sign anything. One afternoon of testing beats twelve months of a contract that misses 40% of your ICP.

What is a lead enrichment API?#

A lead enrichment API is an HTTP endpoint you send a partial record to and get a fuller one back. Think of it like a coat check: you hand over a ticket stub (an email address, a company domain, a LinkedIn URL) and the system returns the whole coat (job title, seniority, company size, tech stack, location, phone, social profiles).

Technically, it is a lookup against one or more contact and company databases, usually with fuzzy matching and a confidence score attached. You call it at three moments:

1. On form submit. A visitor types sara@ramp.com and by the time your thank-you page renders, you know she is a VP of Finance at a 900-person fintech.
2. On import. You buy or scrape a list of 8,000 domains and fan them out to the API to get named decision-makers.
3. On a schedule. Every 90 days you re-run your CRM against the API to catch job changes, which are the single highest-intent trigger in B2B.

The difference between an enrichment API and a UI-based data tool is control. The UI is fine for a rep researching ten accounts. The API is what you need when RevOps wants every inbound lead scored, routed, and assigned before the round-robin timer fires.

What data can a lead enrichment API actually return?#

Not every provider returns every field, and this is where most evaluations go wrong. Teams compare price per credit without checking whether the credit buys the field they actually route on.

• Identity fields — full name, personal work email, alternate emails, LinkedIn profile URL. This is the core of most data enrichment calls and the field set with the highest variance between vendors.
• Role fields — job title, normalized seniority, department, start date in role. Normalization matters more than raw title: "Head of Growth Marketing, EMEA" needs to map to seniority: director, department: marketing or your scoring rules will never fire.
• Company firmographics — legal name, domain, employee count, revenue band, industry code, HQ country. These come from a company graph, which is usually a different (and more accurate) dataset than the person graph.
• Contact channels — direct dial, mobile, switchboard. Phone coverage is the most expensive and most inconsistent field class in the market; expect 20-45% coverage on US B2B and much less in EMEA.
• Technographics and signals — installed tech, hiring velocity, funding events, web traffic tier. Useful for scoring, rarely accurate enough to personalize a first line without a human glance.
• Deliverability status — SMTP-verified, catch-all, risky, unknown. If your provider returns emails without a verification verdict, you are paying twice: once to find, once to verify emails elsewhere.

Use this as a requirements checklist before you look at a single pricing page. Write down the five fields your routing and scoring logic actually depends on, then test only for those. Everything else is noise you will pay for and never query.

How do the main lead enrichment API options compare in 2026?#

Here is the practical shape of the market. Pricing is list pricing at the time of writing and moves; always confirm on the vendor's own page before you budget.

The honest read: there is no single winner, there is a fit question. If your bottleneck is "we have domains but no people and half our sends bounce," an email-discovery-first API like Tomba's solves it directly. If your bottleneck is "our HubSpot company records are empty," Clearbit inside HubSpot is the path of least resistance. If you are building a product on top of contact data, People Data Labs sells you the graph rather than the workflow. And if you would rather buy a verified list than build an enrichment pipeline at all, BookYourData is a legitimate shortcut that skips the engineering step entirely.

Check recent buyer reviews on G2 before you commit, and weight reviews from companies in your region. Coverage is deeply geographic.

Why do published match rates lie?#

Because match rate is a ratio, and the vendor picks the denominator.

A provider quoting "97% accuracy" is usually quoting accuracy on records it returned, not coverage of records you submitted. Those are wildly different numbers. Submit 1,000 contacts, get 400 back, 388 of which are correct, and a vendor can market 97% accuracy while delivering 39% useful coverage.

Ask for both numbers explicitly:

• Coverage = matched records ÷ submitted records
• Accuracy = correct records ÷ matched records
• Effective yield = coverage × accuracy — this is the only number that maps to pipeline

A 55% coverage / 92% accuracy provider (51% yield) beats a 40% coverage / 99% accuracy provider (40% yield) for most outbound teams, even though the second one sounds better in a deck.

Second trap: catch-all domains. Roughly a third of mid-market companies run catch-all mail servers that accept everything at the SMTP layer, so naive verification marks them "valid" and your bounce rate explodes anyway. A serious provider will label them separately and give you a pattern-confidence score instead of a false green light. Tomba exposes this through a dedicated catch-all verifier rather than quietly rounding catch-alls up to "deliverable."

Third trap: freshness. B2B contact data decays at roughly 25-30% per year because people change jobs. A record that was accurate in March can be dead by September. Ask when the record was last observed, not when it was first collected. If the API does not return a last_updated timestamp, treat every record as unknown age.

What does a lead enrichment API really cost?#

Sticker price per credit is the smallest part of the bill. Model these five lines instead:

1. Cost per attempted lookup vs per match. Vendors that charge for misses can double your effective cost on a hard list. Ask directly: "Do I burn a credit on a null result?"
2. Field unbundling. Phone numbers are often 3-10x an email credit. If your pricing page shows one credit price, ask what a mobile number costs.
3. Verification. If emails arrive unverified, add $0.002-$0.01 per record for a verification pass, plus the engineering to chain the two calls.
4. Waterfall overhead. Many teams run two or three providers in sequence to lift coverage. That lifts cost too; a three-vendor waterfall with 60/45/30% step coverage costs about 1.8x a single call for roughly 1.5x the yield.
5. Rate limits and retries. A 10 req/sec ceiling on a 200,000-row backfill is a 5.5-hour job with no failures. Build the queue, or buy a bulk endpoint.

For a concrete anchor: a team enriching 5,000 inbound leads a month with email plus firmographics typically lands between $80 and $350/mo. The same team adding direct dials lands between $400 and $1,200. Tomba's Growth plan at $99/mo covers the first scenario comfortably; see Tomba pricing for the credit math on Starter ($49/mo), Growth ($99/mo), and Pro ($249/mo).

How do you wire one into your stack without regretting it?#

Keep the integration boring. The failure mode is never the HTTP call, it is what you do with the response.

A minimal call looks like this:

curl "https://api.tomba.io/v1/email-finder/asana.com?full_name=Sara+Chen" \
  -H "X-Tomba-Key: $TOMBA_KEY" \
  -H "X-Tomba-Secret: $TOMBA_SECRET"

Four rules that save you a rewrite later:

• Never write directly to the CRM field. Write to a shadow field, compare against the human-entered value, and only promote on higher confidence. Enrichment that silently overwrites a rep's manual correction destroys trust in the data forever.
• Store the confidence score and the source. When a rep says "this title is wrong," you need to know which provider said it and how sure it was. Without provenance you cannot tune the waterfall.
• Cache aggressively, re-enrich deliberately. Cache for 60-90 days. Re-enrich on trigger events (a reply, a website visit, a deal stage change) rather than on a blind monthly sweep. You will cut credit burn 40-60%.
• Gate on verification, not on match. A matched-but-unverified email should not enter a sequence. Route it to a verification step, and drop anything that comes back risky.

For one-off backfills, skip the code entirely. A bulk email finder job handles a CSV in one pass, and a Tomba API key covers the ongoing real-time path once the backfill is done.

Should you build your own enrichment layer instead?#

Almost never, with one exception.

Building means scraping, parsing, pattern inference, SMTP verification infrastructure, IP reputation management, and compliance review. The scraping is the easy 20%. The verification infrastructure is where in-house projects die: you need clean IPs, careful rate control, and someone who understands why a 250 OK from a catch-all means nothing.

The exception is when contact data is your product. If you are selling a data feature to your own customers, owning the graph eventually beats reselling someone else's margin. Below that threshold, a vendor API at $0.02-$0.08 per record is cheaper than one engineer-week per quarter of maintenance.

A useful middle path: buy the raw finding and verification, build the normalization and scoring yourself. Title normalization and ICP scoring are business logic, and business logic should never live inside a vendor.

How do you run a fair 500-row bake-off?#

Do this before any contract conversation. It takes an afternoon.

1. Pull 500 real records from closed-won accounts, not a random sample. You want your ICP, not the internet's average.
2. Strip them to inputs only — name plus domain, or domain only. Keep the verified answers in a separate column.
3. Run the same file through 2-3 providers. Use free tiers or trial credits; most vendors including Tomba, Apollo, and the rest of the field offer enough to test 500 rows.
4. Score coverage, accuracy, and yield per provider, then split by segment: US vs EMEA, under 200 employees vs over, technical vs non-technical titles. Providers win and lose by segment, not overall.
5. Time the calls. If you are enriching on form submit, anything over 800ms p95 is a broken user experience.
6. Price the yield. Divide total spend by correct records returned. That single number ends the debate.

Teams that run this test almost always end up with a two-provider waterfall rather than a single winner, because coverage curves differ by segment. That is a good outcome, not a failure of the test.

Ready to enrich with data you can actually send to?#

Most enrichment projects stall for the same reason: the records come back fast, and half of them bounce. Start with the layer that decides whether your outbound works at all. The Tomba Email Finder returns professional email addresses by domain, name, or company with verification built into the same call, so a matched record is a sendable record. Test it against 25 of your own accounts on the free tier before you spend a credit, then move to the API when the match rates hold up on your list.

Related guides#

• B2B Lead Enrichment in 2026: The Complete Data Playbook
• Clay Enrichment in 2026: How Waterfall Data Enrichment Works
• B2B Data Enrichment Services: The 2026 Buyer's Guide
• ABM Data Enrichment in 2026: Complete Playbook & Tools