TCPA Litigator Scrub: How to Filter Out Professional Plaintiffs Before You Dial or Text

The serial-plaintiff problem in plain English

Not every wrong number is an honest mistake waiting to be forgiven. A small group of people, often working with plaintiff-side TCPA attorneys, deliberately collect phone numbers, wait for an unsolicited call or text, and then file a claim under the Telephone Consumer Protection Act. They are known as professional plaintiffs or serial litigants. In one well-known case, Stoops v. Wells Fargo (W.D. Pa. 2016), the plaintiff had bought at least thirty-five prepaid cell phones for the purpose of filing TCPA suits. One of their numbers sitting in your outbound list can get expensive fast.

Under the TCPA, each unsolicited text or call to a cell phone without proper consent carries statutory damages of $500 per violation, rising to $1,500 per violation if a court finds the contact was willful or knowing (47 U.S.C. § 227(b)(3)). Send a three-message SMS drip to one serial litigant and you are staring at a potential $1,500 to $4,500 claim from a single record. Spread that across even a modest campaign and the exposure stacks up quickly.

The defense is simple in concept and the whole game in practice: do not contact them in the first place. That means knowing which numbers belong to known litigants before a single message goes out.

What is a litigator database?

It is a curated list of phone numbers tied to people with a documented history of filing or threatening TCPA claims. Building one is real operational work: court filings, demand letters and known professional-filer numbers all have to be tracked to find the numbers that keep surfacing in litigation. Ours is refreshed daily. Plaintiffs rotate numbers and port between carriers, so any list decays. A snapshot from six months ago is meaningfully worse than a current one, and you should treat it that way.

The important part: a good database is built upstream of your campaign, not assembled from your own complaints. By the time someone files against you, scrubbing them is pointless. The check has to happen at validation, before the number reaches a dialer, an SMS platform, or a CRM workflow.

How the CheckThatPhone litigator scrub works

The CheckThatPhone /v1/lookup endpoint takes a standard validation request and, when you pass litigatorFilter: true in the body, appends litigator data to the response. The endpoint:

POST https://api.checkthatphone.com/v1/lookup
Authorization: Bearer <key>

A minimal request with the add-on enabled:

{
  "phone": "5551234567",
  "litigatorFilter": true
}

When the number is flagged, the response carries three dedicated fields. An abbreviated example (the full response also includes optDate, dipLrn, dipOcn, and the geo and timezone fields), with a fictional name and number:

{
  "success": true,
  "credits_used": 2,
  "data": {
    "subscriber": "2125550147",
    "action": "unsubscribe",
    "deliverable": "false",
    "reason": "Associated with TCPA Litigator DO NOT CONTACT",
    "nanpType": "mobile",
    "blackList": "true",
    "dip": "success",
    "dipPorted": "false",
    "dipCarrier": "T-Mobile USA",
    "dipCarrierType": "mobile",
    "dipCarrierSubType": "WIRELESS",
    "doNotSms": "true",
    "litigator": "true",
    "litigator_type": "plaintiff",
    "litigator_name": "Jane Example",
    "error": "false"
  }
}

• litigator is the string "true" or "false", like every flag in the response. "true" means the number matched a record in our litigator database.
• litigator_type is how the match was classified: "litigator", "plaintiff", or "agitator". All three carry the same recommended action.
• litigator_name is the name on record for the match. It is present only when a likely name is on record, and it is sensitive data, so don’t log it unnecessarily.

When there is a match, action returns "unsubscribe", reason reads "Associated with TCPA Litigator DO NOT CONTACT", and blackList is forced to "true". That gives downstream automation a clean signal to suppress the number without manual review. You don’t need to parse the name or type. A check on litigator === "true" isolates the litigator matches, and action !== "send" keeps every number we recommend against messaging out of your send queue.

The full field reference is in the CheckThatPhone API docs.

What the rest of the response tells you

The litigator flag is not an island. The same call returns a full carrier and line-type profile that matters for compliance beyond litigation risk.

nanpType tells you whether the number is mobile, landline, or not-mobile, and TCPA consent rules differ by line type, so this is useful even when litigator is "false". dipCarrier, dipCarrierType, and dipCarrierSubType give you the current serving carrier from a live carrier dip at lookup time, not stale registration data. dipPorted flags whether the number has moved to a different carrier than the one it was originally assigned to. And deliverable, blackList, and deactivationDate surface numbers that aren’t SMS-reachable, are blacklisted, or were deactivated by the carrier in the last 45 days.

Put together, one API call handles litigator suppression, line-type gating, and basic deliverability filtering in a single pass.

If your campaign sends SMS to landlines, add landlineSmsLookup: true to the request. That returns dipMessagingLookup, dipMessagingEnabled, and dipMessagingProvider, confirming whether a landline can actually receive a text before you attempt delivery.

Scrubbing at scale: bulk CSV verification

Real-time validation through /v1/lookup is the right call for leads landing in a CRM, form submissions, and any per-record workflow. But for an existing list, an acquired one, a re-engagement segment, a legacy database, calling the endpoint once per number is wasteful.

For big lists, the bulk CSV uploader handles it from the dashboard. Open Bulk CSV, upload your file, and we deduplicate the records and run carrier validation, line-type classification, and any add-ons you have enabled (litigator scrub and landline SMS lookup included) across every unique number. You get a downloadable result file with all the response fields appended as columns. The upload and the result file are hard-deleted within 24 hours, so your data doesn’t sit around longer than the job needs.

This is the practical path for pre-campaign scrubs on lists of tens of thousands or more. Run the job, drop every row where litigator is "true" (or, for SMS, every row where action isn’t "send"), and import only the clean segment into your dialer or messaging platform.

Building litigator suppression into your workflow

A few practical notes:

1. Scrub at acquisition, not just at send. The sooner you catch a litigant number, the less of your stack it touches. Validate on ingest so the number never reaches a sequence in the first place.

2. Re-scrub aging lists. Our litigator data is refreshed daily, so a list that was clean ninety days ago can hold newly flagged numbers today. For high-volume programs, treat the scrub as recurring maintenance, not a one-time gate.

3. Pair it with consent records. Suppression cuts exposure but does not replace documented consent. The two controls do different jobs: consent records defend you on the merits, and litigator suppression removes the most motivated plaintiffs before any contact happens. Our guide to prior express written consent covers what a defensible consent record contains.

4. Check pricing for add-on coverage. The litigator scrub adds 1 credit to the base lookup. The CheckThatPhone pricing page shows how that bills against your expected volume, and the ROI math of running a litigator filter on every SMS send shows when it pays for itself.

The practical bottom line

TCPA serial plaintiffs are a real, quantifiable risk, not a theoretical edge case. The mechanics are blunt: one flagged number, a short message sequence, and a demand letter can produce a four-figure claim before you know anything went wrong. Implementing a scrub takes no legal expertise. It takes routing each number through a validation step that reads the litigator field and suppresses the record when the flag is set.

CheckThatPhone surfaces that flag alongside carrier, line type, porting status, and deliverability in one call, so the compliance check is not a separate integration bolted onto your stack. One request, one response, one suppression decision.

For a full walkthrough of building a compliant outbound program around these controls, see the TCPA litigator scrub use case. The same lookup can also run free state DNC and complainer checks with dncState: true and dncComplainer: true, covering 38 states plus DC alongside the litigator check. And if you also validate numbers for identity verification, the KYC phone verification use case covers how the same fields apply there.