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

_2026-07-18 · Boundstone (https://boundstone.io/blog/tcpa-phone-validation)_


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.

```bash
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"}'
```

```json
{
  "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](/blog/what-is-phone-line-type).)

## 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](/tools/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](/blog/dnc-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.