Use Ekata to add external identity intelligence to a registration or transaction decision. Darwinium maps the identity details from your flow, sends the lookup, and makes selected results available alongside its own journey and device signals.
The package contains two operations. Choose the one covered by your Ekata account and appropriate to the interaction:
| Template | Use | API operation |
|---|---|---|
ekata_account_opening |
Assess a person opening an account | Account Opening, /1.1/account_opening |
ekata_trapi |
Assess a transaction with primary and secondary identities | Transaction Risk, /2.1/transaction_risk |
Example: assess a registration
Install Ekata, import ekata.snippet and add the account-opening template to the registration submission step. Store the provider credential under a name such as ekata_account_key using Secret Management.
Configure the ekata_ao_api_key argument with {{ secret(ekata_account_key) }} and Identity Source (ek_identity_context) with ACCOUNT.
Map the registration fields into the following destinations before the call:
| Registration value | Attribute read by the default configuration |
|---|---|
| First and last name | identity['ACCOUNT'].name.first and .last |
identity['ACCOUNT'].email['PERSONAL'].email |
|
| Telephone | identity['ACCOUNT'].telephone['HOME'].national_number |
| Telephone country hint | identity['ACCOUNT'].telephone['HOME'].geo |
| Address | identity['ACCOUNT'].address['HOME'].street1, .street2, .city, .state, .zip_post_code, .country |
| Client IP | profiling.tcp_connection['PRIMARY'].ip_address |
For example, map a registration body's $.email to the email path above. An email stored under BUSINESS, or a phone stored under MOBILE, will not automatically populate the supplied template's PERSONAL or HOME fields. Adapt the copied template if those are your intended sources.
Set the operation's dependency to include the stage providing those fields, such as LOCAL.REQUEST. The request also supplies the journey ID and timestamp for the account-opening lookup.
Read the account-opening response
Results are mapped under integrations.ekata.account_opening:
| Result group | Examples you can inspect |
|---|---|
| Overall assessment | identity_risk_score, identity_network_score, warnings |
email.valid, email.first_seen_days, email.to_name |
|
| Phone | phone.valid, phone.line_type, phone.country_code |
| IP | ip.risk_score, ip.geolocation_country_code, ip.address_distance |
| Address | address.validity_level, address.to_name |
Make your consuming decision depend on this operation. Choose thresholds and interpretations from the Ekata product contracted for your account; the snippet supplies response data, not a universal accept/reject policy. You could route a registration for review when the provider assessment and a Darwinium device signal both meet your defined criteria.
Example: assess billing and shipping identities
For a transaction, add ekata_trapi instead. Set ekata_trapi_api_key to the secret for that API, primary_context to ACCOUNT, and secondary_context to SHIPPING if those match your mappings.
Here, SHIPPING is an identity context. Within each identity, the template still reads the HOME address, PERSONAL email and HOME phone. The secondary address is therefore:
identity['SHIPPING'].address['HOME']
It is not identity['ACCOUNT'].address['SHIPPING']. Check this distinction before testing. The request includes the event identifier, timestamp, client IP and both identities.
Transaction outputs are under integrations.ekata.transaction, including primary, secondary, ip, identity_risk_score, identity_network_score, alerts, warnings and errors.
Verify the integration
Deploy with test credentials for the selected API. Submit a controlled registration or transaction, then inspect the mapped inputs and the corresponding Ekata output group in Investigations. Check a partial identity as well as a complete one, and verify how your decision handles provider errors or missing results.
If results are absent, first check the selected contexts and execution order. A correctly authenticated request can still assess the wrong or incomplete identity when its input paths do not match your mappings. Continue with Build your first decision to combine the result with other signals.