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 population of individuals — often working with plaintiff-side TCPA attorneys — deliberately collect phone numbers, wait for unsolicited calls or texts, and then file claims under the Telephone Consumer Protection Act. These people are commonly called professional plaintiffs or serial litigants, and a single number belonging to one of them inside an outbound campaign can be expensive.

Under the TCPA, each unsolicited text message or call to a cell phone without proper consent can carry a statutory damage of $500 per violation — and up to $1,500 per violation if the court finds the contact was willful. Send a three-message SMS drip sequence to one serial litigant and you are looking at a potential $1,500 to $4,500 claim from a single record. Scale that across even a modest campaign and the exposure compounds quickly.

The defense is not complicated in concept: don’t contact them in the first place. That requires knowing which numbers belong to known litigants before the message is ever sent.

What a Litigator Database Actually Is

A litigator database is a curated list of phone numbers associated with individuals who have a documented history of filing or threatening TCPA claims. Building one is a real operational discipline. Attorneys and compliance vendors track court filings, demand letters, settlement records, and subscriber data to identify numbers that keep appearing in litigation. Because plaintiffs frequently rotate numbers or port between carriers, the database needs to be refreshed continuously — a static list from six months ago has meaningful decay.

The key insight is that the database is built upstream of your campaign, not derived from your own complaints. By the time someone files against you, it is too late to scrub them. The scrub has to happen at the validation stage, before the number enters a dialer, an SMS platform, or a CRM workflow.

How the CheckThatPhone Litigator Scrub Works

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

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

A minimal request with the litigator add-on enabled looks like this:

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

When the number is flagged, the response includes 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 — boolean flag; true means the number matched a known litigant record.
litigator_type — the category of litigation risk (e.g., TCPA).
litigator_name — the name associated with the litigant record in the database.

The action field will return block and reason will describe the match, giving downstream automation a clean signal to suppress the number without requiring manual review. You do not need to parse the name or type — a simple check on litigator === true or action === "block" is enough to gate the record out of your send queue.

See the full field reference in the CheckThatPhone API docs.

What the Rest of the Response Tells You

The litigator flag does not exist in isolation. The same API call returns a full carrier and line-type profile that is useful for compliance beyond litigation risk:

nanpType tells you whether the number is mobile, landline, or not-mobile. TCPA consent requirements differ by line type, so this matters even when litigator is false.
dipCarrier, dipCarrierType, and dipCarrierSubType give you the current serving carrier from a live carrier DIP, not just the original registration data.
dipPorted tells you whether the number has been ported since it was first assigned — relevant because porting is a common tactic among number collectors.
deliverable, blackList, and deactivationDate surface numbers that are inactive, blacklisted, or have been recently deactivated and reassigned.

Together these fields let you make a single API call that handles litigator suppression, line-type gating, and basic deliverability filtering in one pass.

If your campaign includes SMS to business landlines, add landlineSmsLookup: true to your request. This returns dipMessagingLookup, dipMessagingEnabled, and dipMessagingProvider, confirming whether a non-mobile number is actually capable of receiving text messages before you attempt delivery.

Scrubbing at Scale: Bulk CSV Verification

Real-time validation via the /v1/lookup endpoint is the right approach for leads entering a CRM, form submissions, or any per-record workflow. But if you are working with an existing contact list — an acquired list, a re-engagement segment, or a legacy database — calling the endpoint once per number is inefficient.

For large lists, CheckThatPhone’s Bulk CSV feature handles this directly from the dashboard. Navigate to Dashboard → Bulk CSV, upload your file, and the system deduplicates records, runs carrier validation, line-type classification, and any add-ons you have enabled (including litigator scrub and landline SMS lookup) across every row. You get a downloadable result file with all the response fields appended as columns. Uploaded files and result files are deleted within 24 hours of delivery, so your data is not retained longer than the task requires.

This is the practical path for pre-campaign scrubs on lists of tens of thousands or more. Run the bulk job, filter out 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 practical implementation notes:

Scrub at acquisition, not just at send. The earlier you identify a litigant number, the less processing it receives inside your stack. Validate on ingest so the number never reaches a sequence.
Re-scrub aging lists. Litigator databases are updated continuously. A list that was clean ninety days ago may contain newly flagged numbers today. For high-volume programs, treat litigator scrub as a recurring maintenance step, not a one-time gate.
Combine with consent recordkeeping. Litigator scrub reduces exposure but does not replace documented consent. The two controls work together: consent records defend you on the merits; litigator suppression removes the most motivated plaintiffs before contact ever occurs.
Check pricing for add-on coverage. The litigator scrub is an add-on to the base lookup. Review the CheckThatPhone pricing page to understand how it is billed relative to your expected volume.

The Practical Bottom Line

TCPA serial plaintiffs are a real and quantifiable risk category, not a theoretical edge case. The mechanics are straightforward: one flagged number, a short message sequence, and a demand letter can produce a four-figure claim before you are aware anything went wrong. A litigator scrub does not require legal expertise to implement — it requires routing each number through a validation step that checks the litigator field and suppresses the record if the flag is set.

CheckThatPhone surfaces that flag alongside carrier, line type, porting history, and deliverability data in a single API call, so the compliance check does not add a separate integration layer to your stack. It is one request, one response, one suppression decision.

For a detailed walkthrough of building a compliant outbound program around these controls, see the TCPA litigator scrub use case. If you are also validating phone numbers as part of identity verification, the KYC phone verification use case covers how the same fields apply in that context.