TCPA and cold calling: where phone validation fits (and where it does not)

Cold calling has rules, and the rules are not the fun part. TCPA — the Telephone Consumer Protection Act — governs how you dial and text people in the United States, and it treats wireless numbers differently from landlines. That single difference is why sales and lead-gen teams start asking about phone validation: if your list tells you which numbers are mobile, you can route your dialer accordingly. Useful. But it is easy to over-read what validation gives you. This post draws the line — what phone validation does for TCPA-adjacent work, and the several things it does not do and never will.

First, the disclaimer that matters: this is not legal advice. Boundstone is a data-validation tool, not a compliance service and not a substitute for counsel. Treat everything below as how the data fits into a process a lawyer designs, not as the process itself.

What TCPA actually cares about#

TCPA is about consent, method of contact, and who you are allowed to reach. In broad strokes: calling or texting wireless numbers with an autodialer or a prerecorded message carries restrictions that landline dialing does not, and separately you must honor do-not-call requests — both the national registry and your own internal suppression list. Compliance is a function of consent records, registry scrubbing, and dialing method.

None of that is a data-format question. A number being well-formed tells you nothing about whether the person consented, whether they are on the DNC registry, or whether your dialer configuration is lawful. Keep that separation in mind, because it is the whole point of this post.

What phone validation actually checks#

Phone validation answers a narrow, mechanical question: is this string a possible, correctly-formed number for its region, and what does its numbering plan say about it? Boundstone returns validity, the E.164 form, the country, a national format, and a line-type from the numbering plan.

curl -X POST https://api.boundstone.io/v1/verify/phone \
  -H "Authorization: Bearer bs_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"phone":"+16504472983"}'

{
  "valid": true,
  "e164": "+16504472983",
  "country": "US",
  "line_type": "fixed_line_or_mobile",
  "national_format": "(650) 447-2983",
  "checks": {
    "performed": ["format", "region", "line_type_metadata"],
    "not_performed": ["carrier_lookup", "ported_status", "hlr_liveness"]
  }
}

Read the checks block, because it is the honest part. What ran: format, region, line_type_metadata. What did not: carrier_lookup, ported_status, hlr_liveness. The line type comes from Google's libphonenumber — the number's designated type in its numbering plan, not a live network check. And note the value above: fixed_line_or_mobile. In North America the plan often can't tell wireless from landline, so it says so. It does not guess, and neither should you. (More on what each type means in what phone line type actually tells you.)

Where validation earns its place#

For an outbound team cleaning a list, validation does real, unglamorous work:

• Drop the impossible. Typos, dead formats, wrong-length strings, junk from a form field. No sense burning dialer minutes on numbers that cannot exist.
• Normalize to E.164. One canonical format so your CRM, your dialer, and your reporting stop disagreeing about the same contact.
• Segment by line type. Where the numbering plan cleanly says mobile or fixed_line, you can bucket the list — relevant precisely because wireless dialing carries the heavier TCPA restrictions. Where it says fixed_line_or_mobile, treat that as "unknown," not as a coin flip.

You can run one number at a time, drop a CSV into the dashboard, or hit the bulk endpoint for a whole list. If you want to see it on your own numbers before wiring anything, the phone validator runs the same check in the browser.

Where validation does not fit#

This is the half that keeps you out of trouble, so read it twice.

• It is not DNC scrubbing. Validation never touches the National Do Not Call Registry or any state list. Whether a number is registered is a separate lookup against the official registries — full stop. (We wrote up the distinction in DNC scrubbing vs phone validation.)
• It does not confirm consent. Consent lives in your own records — the opt-in, the form, the contract — not in the shape of a phone number.
• It does not mean the number is live. valid: true means possible and well-formed. It does not mean in-service, reachable, answered, or textable, and it does not tell you the current carrier. Those need a live carrier or HLR lookup — that is the not_performed list by default, and a paid opt-in via hlr:true at 5 credits.
• VoIP is only partly visible. Line-type metadata catches numbers in ranges designated as VoIP. A hosted or ported VoIP number reusing a mobile or fixed-line range looks like a normal mobile or landline to the metadata — only a live carrier lookup would reveal it.
• It is not legal advice. For TCPA and DNC obligations you need the official registries and/or a lawyer who knows your dialing setup. Boundstone is the hygiene layer; it is never the compliance layer.

A sane division of labor#

Think of it as two stages that never blur into one. The hygiene layer — validation — drops invalid numbers, normalizes formats, and segments by line type, so the list you hand downstream is clean and correctly bucketed. The compliance layer — DNC registry scrubbing, consent records, dialing-method decisions, and counsel — decides who you are actually allowed to call and how. Validation makes the compliance layer's job easier by removing noise. It does not replace a single part of it.

The free tier is 250 credits a month, no card, and credits never expire, which is plenty to clean and segment a real list before you decide anything.

The short version#

• TCPA distinguishes wireless from landline, so line-type segmentation is genuinely useful.
• Phone validation gives you format, region and line_type_metadata — plus E.164 — and honestly reports what it did not do.
• line_type is the number's designated type, not a live check. fixed_line_or_mobile means "can't tell," so do not pretend otherwise.
• valid: true is not "live," "dial-able" or "current carrier." Those are carrier_lookup, ported_status and hlr_liveness — not_performed by default.
• Validation is not DNC scrubbing, not consent, and not legal advice. For those, use the official registries and a lawyer.
• Use validation as the input to compliance, never as the answer.