Brazilian lawsuit monitoring: how to get automated alerts for new cases against a CPF

TL;DR: Searching once is a photo. Monitoring is a video. The real risk isn’t today’s cases — it’s the ones that will exist tomorrow. Lawsuit monitoring is the periodic re-verification of a CPF list to automatically detect new cases. Works in 3 tiers: spreadsheet + script (up to 50 CPFs, R$ 24/month), no-code with Make/n8n (up to 500, R$ 100/month), or own backend (thousands, enterprise). LGPD allows it (art. 7 §4 — public data). This guide covers: how it works, 3 real scenarios, architecture, 4 decisions to make, 3 implementation tiers, costs, best practices, and FAQ.

Searching for lawsuits once (see the lawsuit search by CPF guide) only solves half the problem. The real risk isn’t the cases that exist today — it’s the ones that will exist tomorrow. A client can be clean at the time of contracting and, six months later, have three new labor claims. A supplier can enter judicial recovery next quarter. A borrower can receive a tax execution that completely changes the risk analysis.

That’s why continuous monitoring is as important as the initial search. According to the CNJ Justice in Numbers 2024, Brazil receives more than 28 million new cases per year — meaning any CPF’s judicial landscape can change at any time.

This guide covers how automated lawsuit monitoring works, when it makes sense, which decisions to make, and how to implement it at 3 complexity levels.

What is lawsuit monitoring

Lawsuit monitoring is the process of periodically re-verifying a CPF (or list of CPFs) to detect new cases that appeared since the last check. The goal is being automatically notified when something changes, without manual searching.

In practice, the system does 3 things:

1. Stores the current state of each CPF’s cases (which cases exist, their CNJ numbers)
2. Re-queries periodically (daily, weekly, monthly) via API
3. Compares the new result with the previous state and alerts if there’s a difference

3 scenarios where monitoring would have prevented the problem

Scenario 1 — Fintech that approved credit and didn’t monitor

A fintech approved R$ 200,000 in credit for an entrepreneur in January. Judicial analysis at the time: zero cases. In March, the entrepreneur gets hit with a R$ 500,000 tax execution (scheduled BacenJud freeze). In April, stops paying installments.

With weekly monitoring: alert in March. The fintech could have initiated preventive collection, blocked new operations, or reclassified risk. Without monitoring: only discovered when default already existed.

Scenario 2 — Law firm that lost strategic window

A firm represents a corporate client in 8 civil cases. The client, without warning, files for judicial recovery in another state. The firm discovers 2 months later, from the news. During that time, strategies for all 8 cases were misaligned.

With monitoring: alert on the day of recovery filing. Strategy adjusted immediately.

Scenario 3 — Supplier compliance under Súmula 331

A company contracts a cleaning supplier. Initial analysis approved — 2 labor cases, acceptable risk. Six months later, the supplier starts accumulating labor claims but continues normal service. By the time the company discovers, there are 30 new cases with potential subsidiary liability. For the full Súmula 331 risk picture, see labor liability and subsidiary responsibility.

With monthly monitoring: alert when volume went from 2 to 8, well before reaching 30.

Architecture — how it works

List of monitored CPFs + last check state
            ↓
     Scheduler (daily / weekly / monthly)
            ↓
     Vigilant API (queries each CPF)
            ↓
 Comparison with previous stored state
            ↓
If new case detected → fire alert
If nothing changed → silent log

4 decisions before implementing

1. Where to store state

Storage	For whom	Practical limit
Google Sheets / Excel	Small firms	~200 CPFs
Airtable	Mid-size compliance teams	~2,000 CPFs
PostgreSQL / MongoDB	Fintechs, banks	No limit
Internal tool state (Make, n8n)	Teams without dev	~500 CPFs

2. How often to re-query

Risk profile	Frequency	Justification
High-value active credit (R$ 100k+)	Daily	Tax execution can arrive anytime
Active client portfolio	Weekly	Cost/detection balance
Suppliers with active contracts	Monthly	Deterioration is slower
Target shareholders (active M&A)	Daily or every 2 days	Closing window is short

3. What counts as a “real alert”

• Compare CNJ number lists (most precise)
• Filter by role: alert only when CPF appears as defendant (more actionable)
• Threshold: ignore ±1 case variations (reduces noise)
• Alert on any change (more noise, more security — recommended for M&A)

4. How to deliver the alert

Channel	For whom	Advantage
Email	Anyone	Universal
Slack/Teams	Internal teams	Immediate, collaborative
Ticket in management system	Firms	Traceable, with SLA
Webhook to another system	Fintechs	Deep integration

3 implementation tiers

Tier 1 — Spreadsheet + scheduled script (up to ~50 CPFs)

• Google Sheets with monitored CPFs and “last case count” column
• Apps Script with weekly trigger calling Vigilant API
• Compares current total with previous; if different, marks red + sends email
• Zero infrastructure — runs entirely on Google, free

Cost: R$ 0 infra + API usage (~R$ 24/month for 20 CPFs weekly across 3 courts)

Tier 2 — No-code tool (up to ~500 CPFs)

• Make, n8n, or Zapier orchestrating steps visually
• Storage in Airtable, Google Sheets, or tool’s internal state
• Multi-channel alerts (email + Slack + webhook)

Cost: R$ 0-50/month tool + API usage

Tier 3 — Own backend (thousands of CPFs, regulated compliance)

• PostgreSQL/Redis for state
• Scheduled worker (cron, Kubernetes CronJob)
• Batch processing with queue
• Internal dashboard integrated with CRM
• Full audit logging (regulatory requirement for banks)

Cost: R$ 200-2,000/month infra + API usage. Developer docs have examples for all 3 tiers.

Real case — boutique firm with 180 monitored clients

A 6-lawyer corporate firm with 320 clients (180 in active monitoring). Before automation: quarterly manual monitoring, dedicated paralegal 3-4 days/quarter.

Tier 2 implementation (Make + Google Sheets + Vigilant):

• 180 CPFs monitored weekly across 5 courts
• Queries/month: 3,600 (actual with cache: ~2,400)
• API cost: ~R$ 240/month
• Alerts/month: 8-12 (new cases detected)
• 4 serious deteriorations caught in 6 months (recovery, tax execution, supplier labor spike)
• Estimated exposure mitigated: ~R$ 800,000

Cost table by profile

Portfolio	Frequency	Courts	Queries/month	Theoretical cost	Actual (with cache)
20 clients	Weekly	3	240	R$ 24	~R$ 16
50 clients	Weekly	5	1,000	R$ 100	~R$ 65
100 clients	Weekly	5	2,000	R$ 200	~R$ 130
100 suppliers	Monthly	10	1,000	R$ 100	~R$ 70

Cache saves 30-50% in practice. Full pricing at /en/pricing/.

Best practices

• Don’t monitor everyone — focus on high-exposure CPFs to avoid alert fatigue
• Start with 10 CPFs — validate the flow before scaling
• Integrate with workflow — alert should become a ticket with SLA, not just an email
• Document for compliance — who’s monitored, frequency, legal basis, alert recipients, response workflow

Legal — LGPD

Public court data has clear legal basis for continuous monitoring:

• Art. 7, §4 — manifestly public data
• Art. 7, IX — legitimate interest (ongoing risk management)
• Art. 7, VI — regular exercise of rights

No consent needed. Best practice: inform in contract/KYC policy that continuous verification occurs. Maintain audit trail — Vigilant generates automatically.

Glossary

Term	Definition
Lawsuit monitoring	Periodic re-verification of CPFs to detect new cases
Alert	Notification fired when monitoring detects a change
Cache	Temporarily stored result — repeat query within 2 days is free
Alert fatigue	Fatigue from excessive alerts, leading to ignoring them
Batch	Processing multiple CPFs at once
Scheduled worker	Process that runs automatically at defined times
SLA	Service Level Agreement — defined response time for an alert
CNJ number	Unique case ID — used to compare lists between checks

Conclusion

The initial search is step one. Continuous monitoring is what keeps the protection active. Without it, the due diligence you did on day 1 silently ages — and the risk that appears on day 90 isn’t detected until it becomes a problem.

Implementation doesn’t need to be complex. A spreadsheet + Google Apps Script already works for portfolios up to 50 CPFs. Cost: R$ 16-65/month. Setup time: one afternoon. And the first relevant alert it catches can be worth R$ 100,000+ in mitigated risk.

For the full automation flow: automation for law firms covers the 3 integration paths. To understand how monitoring connects with KYC, see judicial KYC. To integrate into your backend, the technical docs at /en/developers/ have the full spec.

---

Monitor your clients’ and suppliers’ lawsuits. 5 free credits on signup, no credit card. Start now.