Home / Companies / Didit / Blog / Post Details
Content Deep Dive

Blocklist Propagation: Making One Confirmed Abuse Case Kill the Whole Network

Blog post from Didit

Aggregate trend data notice

Excluded from normalized aggregate trends after staff review: 3056 posts were attributed to March 2026; 671 shared March 14, 2026. The preceding six-month median was 13.5 posts.

Review evidence: 3,056 posts in March 2026; 671 shared March 14, 2026; preceding six-month median 13.5. Reviewed August 9, 2026.

This company's pages remain public, but its content is excluded from normalized aggregate trends. Unfiltered raw trends and advanced filtering are available to Accelerate and Lead accounts.

Post Details
Company
Date Published
Author
Didit
Word Count
1,771
Company Posts That Month
43
Language
English
Hacker News Points
-
Post removed?
No
Summary

Didit’s Lists API is presented as an enforcement tool for preventing known abusive actors from repeatedly returning through newly created accounts by blocklisting the underlying identifiers associated with a confirmed session rather than only banning an account record. System-created, immutable blocklists exist for 12 identifier types, including faces, documents, phones, emails, IP addresses, device fingerprints, financial accounts, businesses, and custom keys, while customer-managed allowlists can exempt trusted entities and custom lists support other classifications. Using a reference session ID, teams can automatically extract and blocklist identifiers from an investigated verification session, preserving provenance and avoiding manual data-entry errors; similar enforcement can also originate from transactions or vendor records. Entries take effect immediately in future verifications, can be removed to reverse an incorrect action, and generate warnings or declines depending on match confidence, while CIDR-based IP blocking can target infrastructure but risks affecting legitimate users. The approach is positioned for uses such as AI API abuse, trial fraud, marketplace re-registration, and iGaming self-exclusion, while emphasizing that it complements rather than replaces traffic-layer detection and model-layer protections.

Trends Found in this Post

No tracked trend matches for this post yet.

Use This Data

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.