Skip to main content
POST
Add an entry to a list. The value is validated based on the list’s entry type:
  • email: Must be a valid email address
  • phone: Must be a valid international phone number (auto-normalized to E.164)
  • ip_address: Must be a valid IP address or CIDR range (e.g. 192.168.1.1 or 10.0.0.0/8)
  • device_fingerprint: Must be at least 8 alphanumeric characters
  • country: Must be a valid ISO 3166-1 alpha-3 country code (e.g. USA, GBR, ESP). Alpha-2 codes (e.g. US) are accepted and automatically converted to alpha-3.
  • face, document, wallet_address, bank_account, user, business, key: Any non-empty string
All entry values are case-insensitive. Values are normalized on storage (lowercased for most types, uppercased for country codes) and matched case-insensitively during verification. For example, blocking User@Example.COM will also catch user@example.com.
For face entries, use the Upload face endpoint instead — unless you provide a reference_session_id, which handles face blocklisting automatically (including biometric matching).

Request body

Adding from a session

When you provide a reference_session_id, Didit automatically:
  1. Looks up the session (must belong to the same application)
  2. Extracts the value based on the list’s entry type:
    • face → links the biometric data for future matching, sets is_blocklisted on the Face model
    • document → extracts document number, stores full name / issuing state / document type in metadata, sets is_blocklisted on the KYC model
    • phone → extracts the phone number, sets is_blocklisted on the Phone model
    • email → extracts the email address, sets is_blocklisted on the Email model
    • ip_address → extracts the IP from the session’s location data
    • device_fingerprint → extracts the device fingerprint from the session’s location data
  3. Sets reference_session and reference_object_uuid on the entry for traceability
Returns 400 if the session is not found or does not contain data for the requested entry type.

Disambiguating multiple values

If a session has multiple instances of the same type (e.g. two phone numbers from a multi-step workflow), pass both reference_session_id and value. The backend finds the matching instance and returns 400 if the value doesn’t match any data in the session.
If you omit value, the most recently created instance is used.

Referencing transactions, users, and businesses

When blocklisting data from a transaction or vendor user/business, pass the entity’s UUID as reference_object_uuid and indicate the source type in metadata:
This lets you navigate from the blocklist entry back to the original transaction, user, or business in the console.