The label "lead validation service" covers several different jobs. A phone lookup can normalize a number and return line evidence. An email service can report mailbox, domain, or catch-all evidence. An address service can standardize an address and report postal delivery signals. A multi-field service may combine some of those checks, but its final score still reflects the vendor's model rather than your Business policy.

Four service categories and the evidence they return

Lead validation service categories, evidence, limits, and safe routing use
Service category Typical evidence Important limit Safe routing use
Phone validation Normalized format, valid range, country, line type, status, or reassignment Packages and geographic coverage vary; a valid range is not proof of ownership Combine with other contact and risk evidence
Email validation Syntax, MX, mailbox result, catch-all, role, disposable, and reason status Catch-all, greylisting, timeout, and temporary server states remain uncertain Preserve unknown separately from invalid
Address validation Standardization, postal match, secondary-unit, vacancy, and delivery-point evidence Postal and carrier rules are market-specific Apply only when address matters to the Business
Multi-field lead service Several contact checks, cross-field consistency, and a vendor score or recommendation The score hides tradeoffs unless field results and reasons remain available Use field evidence as inputs to your own policy

This table describes common categories, not a universal contract. Verify the exact fields, market coverage, release stage, and error behavior for every provider you evaluate.

Phone services separate format from contactability

A basic phone lookup should answer whether a number can be parsed and normalized. More expensive packages may return line type, carrier, line status, reassignment, or risk evidence. Those are distinct questions and should remain distinct Validation Checks.

The current Twilio Lookup v2 API documents free Basic Lookup formatting and validation, plus optional paid packages. Its response can include E.164 and national formats, a valid boolean, and validation errors. Line Type Intelligence, Line Status, Identity Match, and Reassigned Number are separate packages with their own coverage and access limits. A valid range therefore does not prove that a person owns the number or can be reached on the channel you plan to use.

Email services need an explicit unknown state

Email validation can start with syntax and domain evidence, then add mailbox and provider-specific signals. The result is rarely a clean permanent yes or no. Catch-all domains, temporary mail-server errors, greylisting, and provider timeouts all require a state that is neither valid nor invalid.

The ZeroBounce v2 validation API currently returns a top-level status plus a more specific sub-status. Its documented statuses include valid, invalid, catch-all, and unknown. The status reference lists greylisting, temporary errors, non-response, and timeout conditions under unknown results. Keep that uncertainty visible. Converting every unknown into invalid discards reachable people when a provider or mail server could not answer.

Address services are specific to a delivery system

Address validation is useful when the Business needs a service address, shipping address, or geographic eligibility. It should be neutral when the Lead does not need an address. A postal match also answers a narrower question than identity or intent.

Smarty's US Street Address API reference uses fields such as enhanced match, delivery-point validation footnotes, record type, vacancy, and no-stat indicators to interpret a US address. Its documentation also separates USPS deliverability from delivery by non-USPS carriers. That distinction is a useful warning: address evidence is tied to a country, data source, and delivery system. Do not turn one provider's result into a global address truth.

One provider or several specialists?

When to choose one lead validation provider, several specialists, or local checks
Choice Use it when Main tradeoff Required safeguard
One multi-field provider Its coverage, fields, latency, and failure model meet the full policy Simple integration, but greater dependency on one taxonomy and outage path Require field results and reasons, not only a score
Several specialists Different fields or markets need different evidence Better field fit, but more contracts, mappings, cost controls, and partial failures Normalize results into one stable check model
Local checks plus selected providers Deterministic syntax and normalization can run before paid requests Lower provider use, but local plausibility cannot claim reachability Label local and provider evidence separately

The practical default is local deterministic checks first, then the smallest set of external checks that can change a real decision. Do not buy a signal because a vendor exposes it. Add it only when the Business can define what the result changes, how an unknown is handled, and how operators can review false holds.

Keep provider evidence outside the routing policy

  1. Normalize locally. Parse fields, preserve the submitted value safely, and reject only deterministic malformed input.
  2. Call the required services. Send only the fields each documented check needs and give every request a bounded timeout.
  3. Store independent Validation Checks. Record provider, status, confidence when meaningful, reason codes, duration, and checked time.
  4. Apply the Business policy. Combine evidence into qualified, review, blocked, or error.
  5. Create Delivery attempts only after the gate. A qualified outcome permits routing; it does not prove that any Destination accepted or processed the Lead.

This boundary keeps provider changes manageable. You can replace a vendor, add a market-specific service, or change a package without rewriting the meaning of a Lucidity Validation Outcome.

Provider failures are not negative contact evidence

A timeout, rate limit, unavailable package, authorization problem, or malformed provider response describes the check process. It does not describe the Lead. Record the check as unknown or errored, keep completed local and provider evidence, and apply the configured fallback.

Use blocked when high-confidence evidence says the Lead should not be delivered. Use error when the Validation Run could not complete. Hold ambiguous evidence for review when the policy cannot safely qualify or block it.

Lucidity follows a contactability-first rule: one strong contact path may qualify a Lead unless an independent high-confidence blocker remains. A provider failure by itself should not erase another locally valid contact path. The Lead Validation documentation describes the current outcome and evidence model.

Review data handling before API fields

Validation services process contact data, so the integration review needs more than a feature checklist. Confirm where each endpoint processes data, what the provider retains, which subprocessors apply, how deletion works, and whether the Business may send the data for this purpose. Review the provider's current contract and privacy terms for every market involved.

At runtime, send only the fields required for the selected check. Keep API keys, raw provider responses, and personal data out of logs. Store stable reason codes and support-safe identifiers instead of full contact values wherever the workflow does not need them.

Validation service due diligence checklist

Questions to ask about a lead validation service before routing depends on it
Area Evidence to request Failure to avoid
Coverage Countries, carriers, data packages, field types, and no-data behavior Applying one market's result globally
Response contract Statuses, reasons, versioning, timestamps, and sample errors Depending on an undocumented score
Reliability Timeouts, rate limits, retry guidance, and service status Turning a transient outage into a blocked Lead
Data handling Processing location, retention, deletion, subprocessors, and security terms Sending unnecessary fields or retaining raw payloads indefinitely
Calibration Review overrides, downstream Delivery results, and reason-level reporting Claiming accuracy without your own labeled outcomes

Measure routing decisions separately from provider uptime

Track provider latency, error rate, no-data rate, and cost per check. Then track the outcome the Business actually cares about: qualified, review, blocked, and error rates; review overrides by reason; and Delivery attempts after qualification. Report each number with a denominator and time window.

Lucidity Lead, Validation, and Delivery records are first-party facts. GA4 can supply traffic context, but it is not the record of whether a service found a contact path, whether the Business held a Lead for review, or whether a Destination received a Delivery.

Primary sources checked August 27, 2026

For deeper implementation detail, see the Lead Validation API response guide, compare phone evidence in the phone number validation API guide, review the email validation API field matrix, and place each option in the broader Lead qualification software model.

Frequently asked question

Do I need a single validation vendor, several field-specific providers, or a workflow that combines them?

Use one vendor when it returns every field your policy needs, covers the relevant markets, and exposes clear unknown and error states. Use several specialist providers when phone, email, and address checks need different coverage or evidence. In both cases, keep the Validation Outcome and routing gate in your own workflow so a provider result does not silently become the business decision.

Turn provider evidence into one routing decision

Bring one real validation policy and the checks it depends on. See how Lucidity preserves each result, holds ambiguous evidence for review, and routes from an explicit Validation Outcome to auditable Delivery attempts.

Request a Lead Validation walkthrough