Sales lead validation and channel routing

The most expensive minute of a sales operation is the one a rep spends dialing a disconnected number, leaving voicemail on a fax line, or texting a landline. The signals to avoid every one of those minutes are visible at the moment the lead enters your system — line type, current carrier, deliverability, and timezone — and they are all returned by a single POST /v1/lookup.

Lead validation isn't a fraud problem. It's a routing problem: given what the API just told us, which channel, which rep, and which urgency tier should this lead get? The fields below answer that question.

The fields that drive routing

See the full field reference for every signal returned per lookup.

A complete request

One lookup per lead — no add-ons required for routing:

curl --request POST \
  --url 'https://api.checkthatphone.com/v1/lookup' \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "phone": "8182925409",
    "ip": "136.38.145.14"
  }'

A mobile lead — SMS-first, queue normally, assign to a rep in the timezone surfaced by the IP geo (the example below resolves to Mountain time): 

{
  "success": true,
  "credits_used": 1,
  "data": {
    "subscriber": "8182925409",
    "optDate": "2026-05-23T21:56:26.108Z",
    "action": "send",
    "deliverable": "true",
    "nanpType": "mobile",
    "blackList": "false",
    "ipResult": "valid-v4",
    "dip": "success",
    "dipLrn": "8182925409",
    "dipPorted": "false",
    "dipOcn": "6010",
    "dipCarrier": "AT&T",
    "dipCarrierSubType": "WIRELESS",
    "dipCarrierType": "mobile",
    "dipMessagingLookup": "false",
    "dipMessagingEnabled": "false",
    "geoCountry": "US",
    "geoState": "UT",
    "geoCity": "Salt Lake City",
    "geoMetro": 770,
    "geoSource": "ip",
    "timezone": "America/Denver",
    "tzOffset": 7,
    "error": "false"
  }
}

A landline lead — same demand signal, completely different channel: call-first, no SMS attempt:

{
  "success": true,
  "credits_used": 1,
  "data": {
    "subscriber": "2024561111",
    "optDate": "2026-05-23T22:01:38.691Z",
    "action": "unsubscribe",
    "deliverable": "false",
    "reason": "Not a valid mobile number",
    "nanpType": "not-mobile",
    "blackList": "false",
    "ipResult": "valid-v4",
    "dip": "success",
    "dipLrn": "2024561111",
    "dipPorted": "false",
    "dipOcn": "9211",
    "dipCarrier": "Verizon",
    "dipCarrierSubType": "RBOC",
    "dipCarrierType": "landline",
    "dipMessagingLookup": "false",
    "dipMessagingEnabled": "false",
    "geoCountry": "US",
    "geoState": "UT",
    "geoCity": "Salt Lake City",
    "geoMetro": 770,
    "geoSource": "ip",
    "timezone": "America/Denver",
    "tzOffset": 7,
    "error": "false"
  }
}

The two responses look almost identical to a human glance, but the resulting SDR workflow is different. The point of the validation step is to make that branch automatic before the lead ever lands in someone's queue.

How to wire it up

1. Webhook-time validation (inbound)

Highest-leverage pattern. Every inbound lead — form submit, demo-request, ad-platform callback — fires a webhook into your lead-routing service. Call /v1/lookup from that webhook handler, attach the response fields to the lead record, and route in one pass. Speed-to-lead is the entire game; you do not want to wait for a nightly job.

2. Pre-handoff batch validation (outbound)

For purchased or scraped outbound lists, run the lookup on every row before the list ever enters your dialer. Drop undeliverables, drop litigators, tag landlines so the call-cadence is correct, and split by timezone so each rep gets a list calibrated to their working hours.

3. SLA-tier scoring

Combine multiple fields into a numeric lead score and use it to decide which SLA tier the lead belongs to: fast-lane (mobile + clean + on-shift timezone, route to best closer in under 60 seconds), normal (anything reachable that doesn't meet fast-lane criteria), slow lane (landlines and VoIP, batched call-back queue), dead (gate fields flagged, no rep contact). Tune from your own conversion data.

Inline FAQ

How do we use this to decide between SMS and a phone call?

Branch on nanpType. "mobile" means SMS is the natural first touch — it is the cheapest, fastest, and best-tolerated channel for cold outreach to a personal device. "landline" means SMS will not deliver; call instead. "not-mobile" is usually VoIP or a non-routable line — try email first.

Is there a way to skip dead leads before they hit our SDR queue?

Yes — gate routing on deliverable === "true" AND blackList === "false" AND litigator === "false". Anything that fails should never reach a rep, period. Cheaper than a single rep-minute spent on a disconnected number.

Can we use this on inbound demo-request leads or only outbound lists?

Both. Inbound is where the highest value of this lookup actually sits — you only get one shot at a demo-request lead, and validating that the phone number on the form is reachable, mobile, and in your target geo before the round-robin assignment usually pays back the credit cost in one prevented bad assignment.

What this isn't

Phone validation isn't a substitute for firmographic enrichment or intent data. A reachable mobile number tells you the channel is live; it doesn't tell you that the person on the other end matches your ICP or is in-market. Most teams stack this lookup before the more expensive enrichment APIs — cheap to validate, expensive to enrich, run the cheap check first.

Pricing for this use case

One credit per lead — no add-on charges. Lead volume tends to be lower than the marketing and CRM use cases, so most teams sit on the 1K, 10K, or 100K plan rather than going metered.

See the pricing page for the full grid, or contact us about enterprise volume if you're putting more than 500K leads through per month.

Related

Try it on your list

Free tier: 500 lookups per month, hard-capped. Paid plans start at $5/month or $0.010 per lookup metered.

Get API access Read the docs