Use Deduce Insights to enrich an account interaction with identity, device and network information. Darwinium sends the mapped email and client IP, then exposes returned signals for investigation and decisioning.
The supplied operation is an evaluation request with action reg.eval, making registration a useful starting point. If your Deduce contract requires a different action or API contract, adapt the request before using it on another flow.
Map a registration and configure the lookup
Install Deduce, import deduce.snippet and add deduce_insights to the registration submission step. Map the request email to identity['ACCOUNT'].email['PERSONAL'].email; confirm the actual client IP is available at profiling.tcp_connection['PRIMARY'].ip_address.
Configure the operation:
| Argument | Example or source |
|---|---|
ddsiteid — Site ID |
The site identifier supplied for your Deduce account |
ddapikey — API Key |
{{ secret(deduce_key) }} |
ddistest — Testing? |
true while validating the integration |
ddemail_source |
identity['ACCOUNT'].email['PERSONAL'].email |
ddipaddr |
profiling.tcp_connection['PRIMARY'].ip_address |
Map deduce_key on the deployment target through Secret Management, and set dependencies so the email and IP exist before the call. Use LOCAL.REQUEST for the registration-body mapping.
The template POSTs to https://api.deducesecurity.com/insights, includes the browser user agent, and sets a 3,000 ms timeout. Review that timeout against the latency allowed by your protected flow. The testing argument is a boolean-valued selection; changing it is part of moving from the test configuration to your intended provider environment.
Understand the output
The response is mapped under integrations.deduce.insights:
| Group | Selected fields |
|---|---|
| Correlation | request_id |
| Device | device.ua_browser, .ua_os, .ua_device_type |
| Location | geo.country, .state, .city, .latitude, .longitude |
| Network | network.isp_name, .is_vpn_confirmed, .is_tor, .is_hosting, .is_public_proxy |
| Signals | signals.info, signals.risk; retain trust signals with the custom mapping below |
The supplied file maps trust signals to integrations.deduce.insights.signals.trust. That destination is not recognized by the tested platform schema. In a custom copy, change the trust response mapping's destination to custom.general_purpose['deduce_trust_signals'], preserving its JSONPath source. Import the corrected copy rather than deploying a journey with that diagnostic.
The three signal collections retain the provider's classifications. They are not a single Darwinium risk score. Keep the request ID when investigating a result with the provider.
Connect the result to your policy
For example, a registration decision can consider network.is_tor together with your own device or velocity signal. Make the consuming rule depend on the Deduce operation so it reads the completed response. Choose which returned signals matter for your population and configure the resulting action.
If the lookup is unavailable, the absence of a risk collection does not establish that Deduce assessed the event as trusted. Keep unavailable and assessed results separate in your strategy.
Verify before switching out of test mode
Deploy to a test target, submit a controlled registration and inspect the email, client IP, request_id and returned signal groups in Investigations. Confirm the IP represents the visitor rather than an upstream proxy. Test a missing email and an unavailable service to check your fallback.
Once the request and mappings are confirmed against your Deduce account, review Testing?, credentials and downstream decisions together for production. Changing the flag alone does not verify that your production account or response contract is correct.