The word valid is easy to overread. Google's libphonenumber FAQ defines validity around assignable number ranges and explicitly says the library cannot determine whether a number is assigned to a person or reachable. That boundary should shape the API contract and the routing policy.

Phone validation checks and what they prove

Phone number validation checks, what they establish, and safe routing actions
Check What it establishes What it does not establish Safe routing use
Parse and normalize The input can be interpreted with a stated country or region context That the number is allocated or reachable Store a canonical comparison value and preserve the raw input
Possible number The length fits the selected numbering plan That its prefix is allocated or current Reject impossible length without making a contactability claim
Valid number range Length and prefix match current numbering-plan metadata Assignment, reachability, identity, or consent Keep as local validity evidence
Line type A documented category such as mobile, fixed line, VoIP, or toll-free That the channel works now or that a VoIP number is disposable Choose a channel or review policy without treating type as identity proof
Live status A provider's current network observation, with coverage and error limits Permanent unreachability or consent to contact Record time and provider; review unknown or unavailable evidence
Reassigned-number result Whether reassignment was found since a supplied verification date Who owns the number now or whether consent remains valid Use as dated risk evidence, not a universal validity flag
OTP or call verification Someone with current access completed the challenge Durable identity, future reachability, or marketing consent Keep separate from passive lookup evidence

1. Separate syntax, possibility, and range validity

A parser should answer small questions in order. Can it interpret the characters? Is the length possible for the stated region? Does the prefix and length match an allocatable range in current metadata? Google's libphonenumber project documentation distinguishes the fast, length-based isPossibleNumber check from the fuller length-and-prefix isValidNumber check.

These checks use numbering-plan metadata, not a live carrier session. Metadata also changes as plans change, so pin a library version, update it deliberately, and test important markets after an update. Never translate a parser failure into a claim that a person cannot be contacted by every path.

2. Normalize to E.164 with explicit country context

The current ITU-T E.164 recommendation defines the international public telecommunication numbering plan. Use an E.164 representation as the canonical phone value when parsing succeeds, but keep the original submitted string and the region used during parsing. Normalization makes equivalent formats comparable; it does not add reachability evidence.

Country context matters whenever the input lacks an international prefix. Twilio's Lookup v2 request documentation accepts E.164 or national format and defaults missing country context to the United States. Veriphone v3 also exposes a documented default_country parameter. An explicit Business policy is safer than an environment-dependent guess.

Store at least the raw input, normalized value, selected region, parser or metadata version, status, and reason. Do not overwrite the raw input after normalization.

3. Compare documented provider fields, not accuracy claims

The table below compares official documentation checked August 23, 2026. It is not a ranking and does not imply hands-on testing. Coverage, access, release stage, and paid packages can change, so verify the fields required by your policy before purchase.

Documented phone validation fields for libphonenumber, Twilio Lookup v2, and Veriphone v3
Option Documented baseline Additional evidence Important boundary
Google libphonenumber Parsing, formats, possibility, range validity, and number type Offline geocoding, original carrier mapping, and time zones where available No current assignment or reachability check
Twilio Lookup v2 Basic formatting and validity response Paid packages for line type, line status, identity match, reassignment, SIM swap, and other signals Package coverage and access vary; some packages can return no data
Veriphone v3 Validity, reason, type, country, region, E.164, and original carrier Current mode can return current carrier, line type, and porting evidence Current-carrier resolution does not indicate device reachability

Lucidity does not use Twilio Lookup or Veriphone. They are included as documented examples of different API contracts. Lucidity runs local phone validation first and, when enabled and entitled, uses Trestle Real Contact v2 as its only external phone provider. The Lucidity Lead Validation documentation explains how phone evidence fits with the rest of a Validation Run.

4. Treat line type as channel evidence, not a verdict

Line type can help decide whether an SMS-first workflow is appropriate, whether a toll-free number conflicts with a consumer-contact policy, or whether a number needs review. Twilio documents mobile, landline, fixed VoIP, non-fixed VoIP, toll-free, premium, pager, voicemail, and other values in Line Type Intelligence. Veriphone v3 returns its own documented phone_type taxonomy.

Keep the provider's raw category and map it to an internal reason code. Do not equate VoIP or non-fixed VoIP with a disposable number. The reviewed libphonenumber, Twilio, and Veriphone references do not expose a generic disposable-phone result, so that capability is not publicly confirmed by these sources.

5. Keep status, reassignment, and identity separate

A provider may offer stronger, more volatile signals in separate packages. Twilio's Line Status documents active, reachable, unreachable, inactive, and unknown outcomes for mobile numbers, but the feature is Public Beta, has no service-level agreement, and may not return data for every network. An unknown result is evidence absence, not a valid or invalid verdict.

Twilio's Reassigned Number package is a separate, US-only check that compares reassignment evidence with a supplied last verified date. A no_data_available result is not a safe negative. Identity match and one-time-passcode verification are different checks again; none of these results substitutes for a documented contact-consent policy.

6. Model negative, unknown, and provider failure differently

The response contract should preserve how the result was produced. A malformed input, an invalid numbering-plan range, a provider timeout, a package-specific error, and a successful response with no data are not interchangeable. If every path collapses to valid: false, routing cannot distinguish bad contact evidence from broken infrastructure.

Phone validation response outcomes and safe handling
Outcome Record Safe default
Locally impossible Parser, region, normalized value if any, and specific reason Combine with the Business contact requirement and other contact paths
Provider negative Provider, package, timestamp, status, confidence, and reason Apply only the policy written for that exact signal
Provider unknown Null or unknown field plus provider reason or error code Review or use documented local fallback
Timeout or service error Validator error category, duration, and retry context without credentials Do not turn infrastructure failure into bad-phone evidence
Conflicting checks Every original result and policy version Hold for review rather than silently choosing one provider

7. Minimize the phone data sent and retained

Send only the fields required for the selected provider package. Prefer an authorization header over putting API keys in a URL, keep credentials out of logs, and define retention for raw responses. Twilio marks phone-related Lookup request and response fields with PII retention classifications in its API reference. Veriphone v3 lists bearer authorization as its recommended authentication method.

Logs need operational identifiers and reason codes, not a full phone value or raw vendor payload. Restrict provider calls to Leads and Workspaces that are allowed to use them, and make regional coverage part of the configuration rather than an assumption.

8. Use one phone check inside the broader Validation Run

Lucidity records phone normalization, provider, status, confidence, reason codes, and provider evidence within one phone Validation Check. The overall Validation Run also considers the configured contact requirement, email and other checks, duplicates, and independent risk evidence before it produces a Validation Outcome. A valid email can preserve a contact path when a phone signal is soft, while strong phone or compliance evidence can still hold the Lead for review.

Provider timeouts preserve local phone evidence and record a validator error instead of declaring the phone invalid. That distinction follows the broader Lead qualification checklist: one weak or missing field should not erase a reachable human, and one plausible field should not erase independent high-confidence risk.

Phone number validation API selection checklist

  1. Name the decision. Decide whether the API supports normalization, channel choice, contactability review, identity proof, or compliance evidence.
  2. Write the evidence boundary. Document what every field establishes and what it cannot prove.
  3. Verify market coverage. Check country, carrier, number type, access, release stage, and no-data behavior for the Businesses you serve.
  4. Preserve unknown and error states. Never map provider absence or timeout to a negative phone verdict.
  5. Test policy outcomes. Cover malformed input, national format, valid ranges, VoIP, toll-free, reassignment unknown, timeout, and conflicting contact paths.
  6. Measure with denominators. Report provider negatives, unknowns, review holds, overrides, and downstream Delivery attempts separately.

Use the Lead qualification software guide to place phone evidence inside the larger category, and What Is a Qualified Lead? to define the operational decision before choosing a provider.

Primary sources checked August 23, 2026

Frequently asked question

Which phone checks improve contactability without treating one provider signal as proof that a person is unreachable?

Normalize with explicit country context, check numbering-plan possibility and validity, record line type, and request live status or reassignment evidence only when the routing policy needs it. Keep each result, provider, timestamp, confidence, and reason separate. A valid format, carrier, VoIP type, or missing provider response does not prove that a person is unreachable, so ambiguous evidence should produce review or a documented fallback rather than an automatic block.

Route from complete Validation evidence

Bring one Business, its required contact method, and the phone signals you rely on. See how Lucidity records each Validation Check, holds ambiguous evidence for review, and routes only from an explainable Validation Outcome.

Request a Lead Validation walkthrough