Assess an email supplied during registration, login or checkout. The AtData package can add email verification and intelligence attributes to the event, which you can combine with Darwinium's behavioral and device signals before choosing an action.
Choose the service you have access to
Install AtData and import atdata.snippet. It contains two model-operation templates:
| Template | Request | Use |
|---|---|---|
atdata_email_verification |
api.towerdata.com/fr |
The packaged verification/risk lookup |
atdata_email_intelligence |
api.towerdata.com/v5/td |
An intelligence lookup with optional requested fields |
These are the endpoints in the supplied package. Confirm your AtData subscription and key support the selected service; a key for a different product or API version may require adapting the request.
Configure a registration lookup
Suppose a registration submission contains:
{"email":"alex+signup@example.com","first_name":"Alex","last_name":"Lee"}
Map these values in the submission step:
| Source | Destination |
|---|---|
$.email |
identity['ACCOUNT'].email['PERSONAL'].email |
$.first_name |
identity['ACCOUNT'].name.first |
$.last_name |
identity['ACCOUNT'].name.last |
Add the selected template to that step and include LOCAL.REQUEST in its dependencies. For verification, configure:
| Argument | Example |
|---|---|
atd_api_key |
{{ secret(atdata_key) }} |
atd_email_source |
identity['ACCOUNT'].email['PERSONAL'].email |
atd_name_source |
identity['ACCOUNT'].name |
atd_reference_id |
{{ identifier }} |
Map atdata_key using Secret Management. The source arguments are attribute paths, while the reference ID is a runtime value. Replace the packaged literal event.identifier default with the expression above if you want the current event's identifier sent for correlation.
For intelligence, use the equivalent atdei_api_key, atdei_email_source and atdei_name_source arguments. atdei_query_params supplies the requested field selection; choose the fields supported by your AtData agreement.
Preserve the original email value
The email-source argument selects an attribute; the template then reads its value at runtime. Supply the original email, including any plus tag. Darwinium's Call URL handling percent-encodes runtime URL values, so you do not need to pre-encode the email or add another encoding pass.
Use a plus-tagged address in your integration test and confirm that the provider receives the same address. A field containing the attribute path as literal text indicates that the runtime expression was lost while adapting the template.
Use the returned attributes
Both templates map selected fields under integrations.atdata.email:
| Result | Example attributes |
|---|---|
| Email validation | email_validation.status, .status_code, .domain_type, .role_account |
| Risk | risk.score, .tumbling_risk, .query_id |
| Email activity | eam.date_first_seen, .longevity, .velocity, .popularity |
| Domain activity | dam.date_first_seen, .longevity, .velocity, .popularity |
The intelligence template also contains mappings for additional subscribed fields. Their presence depends on the request and provider response; an absent optional field is not a negative assessment.
Give the consuming rule a dependency on the AtData operation. Use the returned validation status and risk fields according to your provider's definitions, then combine them with other signals in your decision strategy. If both templates run on one event, their shared output namespace can overlap; separate the destinations in your custom copies when you need to retain both responses independently.
Verify with representative email inputs
Deploy to a test target and inspect the event's mapped email and AtData fields. Include a plus-tagged address, a missing email and a provider-rejected request. Verify the request correlation ID reaches the service as a value, and that a timeout or missing assessment follows your chosen fallback rather than silently counting as low risk.