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 but well-documented 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. 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 a statutory damage of $500 per violation, rising to $1,500 per violation if a court finds the contact was willful. 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 a litigator database actually is

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. Attorneys and compliance vendors track court filings, demand letters, settlement records, and subscriber data to find the numbers that keep surfacing in litigation. Plaintiffs rotate numbers and port between carriers, so the 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:

{
  "phone": "5551234567",
  "nanpType": "mobile",
  "dipCarrier": "T-Mobile USA",
  "dipCarrierType": "WIRELESS",
  "dipCarrierSubType": "MVNO",
  "dipPorted": true,
  "litigator": true,
  "litigator_type": "TCPA",
  "litigator_name": "John A. Doe",
  "deliverable": true,
  "action": "block",
  "reason": "litigator match"
}

• litigator is a boolean. true means the number matched a known litigant record.
• litigator_type is the category of litigation risk (for example, TCPA).
• litigator_name is the name on the litigant record in the database.

When there is a match, action returns block and reason describes it, which gives downstream automation a clean signal to suppress the number without manual review. You do not need to parse the name or type. A check on litigator === true or action === "block" is enough to keep the record 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, not stale registration data. dipPorted flags whether the number has moved since it was first assigned, which is worth noting because porting is a favorite tactic among number collectors. And deliverable, blackList, and deactivationDate surface numbers that are inactive, blacklisted, or recently deactivated and reassigned.

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 business landlines, add landlineSmsLookup: true to the request. That returns dipMessagingLookup, dipMessagingEnabled, and dipMessagingProvider, confirming whether a non-mobile number 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 feature handles it from the dashboard. Go to Dashboard, then Bulk CSV, upload your file, and the system deduplicates records and runs carrier validation, line-type classification, and any add-ons you have enabled (litigator scrub and landline SMS lookup included) across every row. You get a downloadable result file with all the response fields appended as columns. Uploaded files and results are deleted within 24 hours of delivery, so your data does not 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 action is block, and import only the clean segment into your dialer or messaging platform.

Building litigator suppression into your workflow

A few notes from doing this in production:

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. The databases update constantly. 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.

4. Check pricing for add-on coverage. The litigator scrub is an add-on to the base lookup. The CheckThatPhone pricing page shows how it bills against your expected volume.

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 history, 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. If you also validate numbers for identity verification, the KYC phone verification use case covers how the same fields apply there.