Phone validation for affiliate marketers and lead-gen marketplaces

Lead generation is one of the few verticals where both sides of the trade have a direct financial incentive to validate every phone number. Affiliates and lead-gen networks are paid on lead acceptance, not lead volume — bad leads get rejected, refunded, or worse, dragged into a TCPA claim months after the fact. Advertisers buying those leads pay per accepted lead and refuse to pay for invalid ones, then quietly downrank the affiliate's acceptance rate the next time around. The whole marketplace runs on the assumption that the phone number on the lead is real, reachable, the right line type, and not on a litigator list.

Validating that assumption used to be a buyer-side problem solved hours after the post. With POST /v1/lookup it's a single call inside the form-submit handler — same as sending the lead, just one extra credit per number — and the validation metadata travels with the ping. Buyers integrate against the metadata; sellers deliver cleaner leads; both sides insulate themselves from the worst TCPA exposure in the funnel.

Who this is for

The fields that decide saleability

A handful of fields determine whether a lead is sellable, which buyer tier accepts it, and what its expected payout is.

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

A complete request

One call per lead, with the litigator filter on (essentially mandatory in this space):

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",
    "litigatorFilter": true
  }'

A sellable lead — premium tier, ready to ping any buyer:

{
  "success": true,
  "credits_used": 2,
  "data": {
    "subscriber": "8182925409",
    "optDate": "2026-05-23T21:55:43.723Z",
    "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",
    "litigator": "false",
    "litigator_type": "",
    "litigator_name": "",
    "geoCountry": "US",
    "geoState": "UT",
    "geoCity": "Salt Lake City",
    "geoMetro": 770,
    "geoSource": "ip",
    "timezone": "America/Denver",
    "tzOffset": 7,
    "error": "false"
  }
}

An unsellable lead — the kind of result that, if it reached a buyer's outbound call list, would become a TCPA claim within the quarter. The action: "unsubscribe" and the populated litigator fields together make this a hard discard: 

{
  "success": true,
  "credits_used": 2,
  "data": {
    "subscriber": "2627834719",
    "optDate": "2026-05-23T21:56:03.699Z",
    "action": "unsubscribe",
    "deliverable": "false",
    "reason": "Associated with TCPA Litigator DO NOT CONTACT",
    "nanpType": "mobile",
    "blackList": "true",
    "ipResult": "valid-v4",
    "dip": "success",
    "dipLrn": "2627834719",
    "dipPorted": "false",
    "dipOcn": "9327",
    "dipCarrier": "AT&T Wisconsin",
    "dipCarrierSubType": "RBOC",
    "dipCarrierType": "landline",
    "dipMessagingLookup": "false",
    "dipMessagingEnabled": "false",
    "litigator": "true",
    "litigator_type": "litigator",
    "litigator_name": "Jean Zoulek",
    "geoCountry": "US",
    "geoState": "UT",
    "geoCity": "Salt Lake City",
    "geoMetro": 770,
    "geoSource": "ip",
    "timezone": "America/Denver",
    "tzOffset": 7,
    "error": "false"
  }
}

The ping-post integration shape

The canonical lead-gen integration. Same pattern works for direct affiliate-to-advertiser flows and for ping-post aggregator platforms.

1. Validate at form submit (seller side)

The form-submit handler calls /v1/lookup with litigatorFilter: true and stores the response on the lead record. The user sees a "thank you" page immediately — the lookup adds ~150ms server-side, not in the user's perceived latency. If the response is a hard reject (deliverable false, litigator true, blackList true), the lead never enters the marketplace.

2. Ping buyers with the validation metadata

The ping payload to each buyer includes the relevant validation fields: nanpType, dipCarrierType, dipCarrierSubType, dipPorted, ipResult, geoState. Buyers' acceptance rules typically look like "premium tier accepts mobile + clean + ipResult match" and so on. Their bid is the function of the metadata.

3. Buyer re-validates on post (buyer side)

Sophisticated buyers do not trust the ping metadata blindly. On post, they call /v1/lookup independently against the phone number and confirm the seller's claims match. Any divergence (seller claimed mobile, buyer sees VoIP) shows up in seller quality scoring and downranks future bids. The cost of the buyer-side lookup is part of the cost of accepting the lead — one credit, well under any per-lead margin.

4. Periodic re-scoring (both sides)

Numbers in the recent lead history get re-validated on a schedule — weekly for active campaign sources, monthly for archival. A phone that was clean at form-submit but has since landed on the litigator list, been ported, or been deactivated gets flagged so the seller knows their source is going stale and the buyer knows not to recontact.

Inline FAQ

Where in the ping-post flow should the lookup happen?

On the seller side, call it inside the form-submit handler before you ping any buyer. The ping payload then includes validation metadata so buyers can score the lead. On the buyer side, re-call it on receipt of the post — never trust the seller's metadata blindly. Both sides should keep the lookup credit cost in their unit economics.

Will buyers actually accept leads with our validation metadata attached?

Most lead buyers in TCPA-exposed verticals (insurance, mortgage, solar, debt relief) now require some form of upstream phone validation as part of their intake contract. Attaching the response fields to the post payload makes you easier to onboard with serious buyers and gives them an audit trail when a complaint is filed.

How do we keep this from killing our conversion rate?

You do not block the form submit on the lookup result — the user has already converted. You make the routing decision after submit: ping the buyer with the full validation metadata and let the buyer's acceptance rules decide. Slow buyers can fall back to a secondary buyer; failed validation goes to your internal trash bucket or a lower-tier buyer that wants the volume.

Do you flag duplicates across multiple submissions?

CheckThatPhone validates the phone number itself; it does not maintain a cross-tenant duplicate database. Most lead-gen networks layer their own duplicate suppression on top, keyed on the phone number plus a recency window. The two layers compose cleanly — our validation, your dedupe.

What this isn't

Validation does not certify consent. A phone number can be clean on every field above and still be wrong to contact under the TCPA if the underlying consent record is weak. In the affiliate space specifically, the FCC's 2024 ruling closed the multi-buyer consent loophole; validation is one layer of a defensible compliance stack, not a substitute for one-to-one prior express written consent. Pair the lookup with a real consent capture step on every form and a defensible suppression list for opt-outs.

Pricing for this use case

Two credits per lookup with the litigator filter on (one for the standard lookup, one for the litigator check). Most networks run high enough volume to sit on the 100K plan or PAYG.

For aggregator networks pushing seven-figure monthly lookup volume, the enterprise contact form is the right starting point — we can quote against a real volume and SLA profile.

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