Lead Enrichment API: Validate Matches Before You Sequence

A lead enrichment API resolves a person from fragments, and the number that should govern your integration is the confidence threshold at which you allow that resolution into a sequence. Set it too low and you email the wrong human with the right company's context, which is the worst possible combination. The decision changes with your identifier quality: a pipeline fed by verified work emails can run a permissive threshold safely, while one fed by name and company alone cannot.

Treat Resolution as the Product

Company enrichment answers a question about an organization, and getting it slightly wrong produces a slightly wrong firmographic. Person enrichment answers a question about a human being, and getting it wrong produces an email addressed to someone who does not hold the role you described.

That asymmetry should shape the whole evaluation. You are not buying attribute coverage, you are buying a judgment about identity, and the vendor's willingness to quantify that judgment is the main thing separating serious providers from list resellers.

Start by cataloguing which identifiers you actually hold at the moment enrichment runs. The People Data Labs person enrichment input parameters show the shape of a well-specified match interface: a request needs profile, email, phone, email_hash, lid, or pdl_id, or else a name combined with a company, school, location, or other locating attribute. Apollo's people enrichment endpoint accepts name, first_name and last_name, email, hashed_email, linkedin_url, domain, and organization_name on a POST /people/match call.

The hashed_email and email_hash parameters deserve a note during vendor selection. They let you resolve identity without transmitting the raw address, which matters when your legal team is reviewing what leaves your systems.

Set the Confidence Floor From Published Behavior

Most enrichment integrations are built without ever choosing a threshold, which means they run at whatever the default happens to be.

People Data Labs documents min_likelihood as an integer with a default of 2, and states that a response returning a likelihood score of 2 will have roughly a 10 to 30 percent chance of being the person requested. It recommends 6 or higher where high accuracy is needed. It also notes two hard ceilings: requests made with only name and location rarely exceed 4, and email-only requests seldom exceed 6.

Read those ceilings carefully, because they describe your pipeline rather than the vendor. If your inbound form captures a name and a country, no threshold setting will produce high-confidence person resolution, and the correct response is to change what you collect instead of loosening the floor.

Apollo exposes the same idea through billing. Its documentation describes a base cost of 1 to 9 credits per person, 1 credit for demographics or email, an additional 8 credits if a mobile phone is returned, zero credits consumed on no match, and no demographic credit charged when match_confidence is none. That last detail is the useful one: the API distinguishes a confident resolution from an unconfident one and tells you which you received.

Our view: if a provider cannot express confidence as a number you can threshold on, treat every record it returns as unverified and route it to research rather than to a sequence. An enrichment API without an abstention signal is a list, sold by the request.

Handle Job Changes as the Default Case

Contact data decays as people change roles, and the field that decays is the one determining whether your message still makes sense. A person who moved roles eight months ago will still enrich cleanly against a stale profile, and nothing in the response will look wrong.

Require an observation date on every returned employment field, separate from the response timestamp. A title delivered today and observed fourteen months ago is a different asset from one observed last week, and only one of them supports a message that opens with the recipient's current responsibilities.

Then decide what your system does with movement. Two patterns work:

• Treat a job change as a suppression event, pull the record from active sequences, and re-qualify it against ICP before any send
• Treat a job change as a trigger, route it to a rep with the old and new company both visible, and start a deliberately different conversation

Both are defensible. What fails is the third pattern, where the new employer overwrites the old one silently and a sequence written for the previous company keeps running.

Make the Sequence Fail Closed

The integration decision that carries the most downside is what happens between enrichment and send.

Build the pipeline so an unresolved record cannot reach a sequence. Concretely: enrichment runs, the confidence value is written to a field, and the sequence entry condition requires that field to clear your floor. A record below the floor queues for review and stays out of the send.

That ordering matters because the alternative is a fallback token. Personalization built on an enriched field with a default value will produce a send when enrichment fails, and the message will be generic in a way the recipient can detect. Fallbacks are appropriate for optional decoration and inappropriate for anything load-bearing.

Check rate limits against this design. Apollo's documentation shows a 429 response stating a maximum of 600 calls per hour for api/v1/people/match on certain plans. A 600-per-hour ceiling supports enrichment at form submission comfortably and requires scheduling for a bulk backfill, so confirm the limit on your specific plan before designing a real-time path.

Also confirm the asynchronous cases. Apollo documents that reveal_personal_emails and reveal_phone_number are boolean parameters defaulting to false and potentially consuming credits, with phone reveal requiring a valid webhook_url. A webhook-delivered field arrives after the initial response, so any logic that assumes a complete record on the first call will behave unpredictably.

Price the Real Unit and the Suppression Path

Compare providers on cost per usable record, not cost per request. A usable record clears your confidence floor, carries the fields your message needs, and is not already suppressed.

cost per usable record = total spend / records above threshold that passed suppression

Run suppression before enrichment wherever the data allows it. Enriching a record you were never permitted to contact spends credits to produce a liability. Load your customer list, opt-outs, competitors, and any regional exclusions into the step ahead of the API call.

Then settle the commercial terms that vary most across this category: what defines a credit, whether unused credits expire, overage pricing, retention rights for enriched values after termination, and whether the provider permits you to store the returned data in a warehouse you control. That last permission is what lets you audit a match months later, so confirm it in writing instead of assuming it.

LeadHaste practice: we store the raw enrichment response alongside the request that produced it and the confidence value at the time of the decision. When a rep disputes a match, that record answers the question in seconds. It is our operating rule, not a provider requirement, and it is the only reliable way we have found to distinguish a bad vendor from a bad threshold.

Run the Release Test

1. Build a sample of people you can verify by hand, weighted toward hard cases
2. Run it at several min_likelihood or confidence settings and record accuracy at each
3. Choose the floor where false matches reach near zero, then accept the resulting volume
4. Verify observation dates exist on employment fields
5. Simulate a timeout and a rate limit, then confirm no record entered a sequence
6. Re-run the sample after 30 days to measure decay on identical people

Step three is where discipline pays. The volume you lose by raising the floor is volume that would have produced misdirected messages, and the cost of those lands on your sending domains rather than on your credit balance. For the account-side equivalent of this exercise, see our data enrichment API buyer's test.

We can map your identifier quality, set the confidence floor, and build the fail-closed sequencing path with your team during a free ICP and campaign-fit discovery call. Book your free ICP and campaign-fit discovery call →