Custom Data Enrichment

🚧

Custom Data Enrichment is only available for Premium and Enterprise customer.

📘

Best Practices

Please reach out to our support team before implementation. We will review your use case together to design the best implementation possible and ensure your custom data provides the most effective detection signals.

Supported integrations

Why and when use Custom Data Enrichment?

Your application tracks specific flows and internal signals that can directly assist our detection engine in identifying complex threats. Instead of keeping this context siloed in your backend, passing it to DataDome provides the extra layer of intelligence needed to distinguish legitimate users from advanced bots.

Key scenarios include:

Business Intelligence & JWT Claims Extraction: If your traffic is authenticated via JWT, you can extract specific attributes (claims) directly from the token at the edge—such as tenant_id, user_role, or subscription_tier—and pass them to DataDome. This allows the engine to apply more granular detection logic based on the user's authenticated profile.

Internal Security Flags: If your backend security systems (e.g., WAF, fraud engine) have already flagged a user as "suspicious" or "high_risk," you can pass this verdict to DataDome to enrich our Engine.

You can append up to 6 custom attributes to the DataDome payload. These fields are strictly typed.

Privacy Requirement

📘

Do not inject PII (Personally Identifiable Information) such as plain-text email addresses, names, or phone numbers. It is the sole responsibility of the customer to ensure that no Personally Identifiable Information (PII) is sent to DataDome through the Custom Data Enrichment feature. DataDome cannot be held responsible for PII inadvertently submitted via custom fields.

Anonymization guidance for the UserID field

If your UserID is or could be derived from PII, you must anonymize it before sending it to DataDome. The following approaches are accepted, from most to least recommended:

1. Use an opaque internal identifier (Recommended)

The safest approach is to use an internal identifier that has no direct relationship to any PII — such as an auto-generated UUID stored in your database. This requires no hashing and provides excellent detection quality, as the ID remains consistent across sessions.

UserID: "a3f2c1d4-7b8e-4f2a-9c1d-3e5f7a9b2c4d"`

2. SHA-256 with a secret salt

If you must derive the UserID from a PII field (e.g., email), use SHA-256 hashing combined with a secret. Plain SHA-256 without a salt is not sufficient under GDPR, as it is reversible via rainbow tables and therefore does not constitute proper anonymization.

const crypto = require('crypto');
const salt = process.env.DATADOME_HASH_SALT; // Secret, stored securely
const userId = crypto
  .createHmac('sha256', salt)
  .update(rawEmail.toLowerCase().trim())
  .digest('hex');

Limitless possibilities via custom logic

Because this feature is implemented directly within your edge code (e.g., CloudFlare Worker or AWS Lambda), the possibilities are virtually limitless.

You define the business logic. If you can extract a value from the request headers, cookies, or compute it using your own algorithms at the edge, you can inject it into the DataDome detection engine.

This feature is available for integrations where the logic allows for payload modification prior to the API call. Currently supported on: