TCPA litigator scrub for SMS and outbound campaigns

Every outbound SMS or call program in the US runs on the same bet: that the next number on the list is a customer, not a plaintiff waiting to file. The math of that bet is one-sided. One serial litigator in a campaign can recover statutory damages from $500 per message on a basic claim to $1,500 per message for willful violations under the TCPA — and many professional plaintiffs have entire lists of carriers and numbers they cycle through specifically to collect them.

The cheap part of avoiding that fate is knowing in advance which numbers belong to known litigators. That is exactly what the litigatorFilter add-on does.

The fix: one boolean on every lookup

Enable litigatorFilter: true on any request to POST /v1/lookup. We check the number against an internal TCPA litigator database that is continuously updated, and we return three new fields alongside the normal carrier data. The check costs one additional credit per lookup — deterministic, no surprise billing.

Once you see a positive match, route the contact out of your campaign. The action field on the response will already be set to unsubscribe with a reason of "Associated with TCPA Litigator DO NOT CONTACT", so you can wire the suppression directly off that field without writing custom litigator-detection logic.

What you get back

The litigator filter returns these three dedicated fields, in addition to the standard response:

Field	Type	Example	Meaning
`litigator`	boolean / string	`"true"`	True if the subscriber is a suspected TCPA litigator. Treat any truthy value as do not contact.
`litigator_type`	string	`"plaintiff"`	Classification: one of `litigator`, `plaintiff`, `agitator`.
`litigator_name`	string	`"John Smith"`	Name on record. Treat as sensitive — useful for audit trails, not for display in customer-facing UI.

See the Litigator Filter field group in the docs for the full reference alongside all the other fields a lookup returns.

A complete request

Single lookup with the filter on:

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

A positive-match response looks like this:

{
  "success": true,
  "credits_used": 2,
  "data": {
    "subscriber": "8016667777",
    "action": "unsubscribe",
    "deliverable": "false",
    "blackList": "true",
    "litigator": "true",
    "litigator_type": "plaintiff",
    "litigator_name": "John Smith",
    "reason": "Associated with TCPA Litigator DO NOT CONTACT",
    "nanpType": "mobile",
    "geoState": "UT",
    "geoSource": "area-code",
    "timezone": "America/Denver"
  }
}

Notice credits_used: 2 — one credit for the standard lookup, one for the litigator check. If the number had matched no litigator, you'd see litigator: "false" and the recommended action would still be send.

How to wire it up

Three integration patterns, depending on how your campaign infrastructure is built:

1. Pre-flight scrub on list upload (batch)

Run every uploaded list through the API once, before it ever enters your campaign tool. Flag and quarantine litigator matches. Pros: cheapest pattern, one credit per number scrubbed. Cons: misses anyone added to the litigator database after the upload — rerun periodically.

2. At send-time before each message (lazy)

Hit the API right before dispatching each individual message. Pros: always current, catches last-minute additions to the litigator list. Cons: highest credit consumption (one call per send), adds a network hop to every message.

3. Nightly suppression-list rebuild (background)

A scheduled job rescans your active contact list every 24 hours and refreshes a separate do-not-contact table that your campaign tool reads. Pros: amortizes cost, keeps the litigator check off the hot path. Cons: 24-hour delay between database update and your tool reflecting it — usually a fine tradeoff.

Inline FAQ

Does enabling litigatorFilter slow the request down?

The litigator check is a local database lookup that happens in the same call as the carrier DIP — typically tens of milliseconds added, well inside the same response.

Does this replace consent records?

No. Even a scrubbed number can still be wrong to contact if you do not have the underlying consent. Treat litigator data as one safety layer on top of your consent records, not a substitute.

How current is the litigator database?

Continuously updated from the upstream provider that maintains it. We do not publish a per-record timestamp, but freshness is operationally treated as continuous, not a periodic dump.

What this isn't

This is not a legal-compliance attestation. We do not certify that scrubbing with our database eliminates TCPA exposure — consent records, internal opt-out lists, do-not-call registry compliance, and your own AUP all still apply. The litigator filter is one defensive layer designed to catch the worst-case names before they enter your funnel, not the only layer you should run.

Pricing for this use case

The litigator filter costs one extra credit per lookup it's enabled on. Combined with the base lookup credit, a litigator-scrubbed call is 2 credits.

Concrete math:

10,000 numbers scrubbed once on the 10K plan — 10,000 × 2 credits = 20,000 credits. First 10,000 are included; remaining 10,000 are overage at $0.003/credit = $30 base + $30 overage = $60/month.
10,000 numbers scrubbed once on Pay As You Go — 20,000 credits × $0.010 = $200/month. PAYG is the right pick only if your volume is low or highly variable.
100,000 scrubbed on the 100K plan — 200,000 credits. 100,000 included, 100,000 overage at $0.001/credit = $100 base + $100 overage = $200/month.

See the pricing page for the full plan grid.

Field reference: Litigator Filter in the docs
Compliance background: What Businesses Need to Know About TCPA and Phone Validation
Wider context: How Phone Validation Helps Prevent Fraud
Back to all use cases