Actioning on Darwinium

Darwinium can make real-time decisions and be used to decide actions to perform on risky or trusted interactions.

Use Darwinium to...

Receive data

• Through header enrichment at any step
• From response of an API call to Darwinium

Best for when you want to own the real time action, by just receiving Darwinium data and signals.

Perform direct intervention

• Proxy actions to redirect/terminate
• Dynamic content change

Best for when you want Darwinium to handle the real time action, no developer time needed.

Alert & create cases

• Call URL for alert generation
• Call URL for case management

Best for when the 'action' is not in real-time, but instead is creating an alert or a case for investigation.

Receive Data

Best for when you want to own the real time action, by just receiving Darwinium data and signals.

Header Enrichment

Darwinium attributes can be added directly to the headers of any request or response. Those become available to your systems that handle the request to inform on what action to take.

Any time prior:

0. Logic to execute on an interaction is defined in a Darwinium Step. When changed and 'deployed' from the Darwinium Portal, the revised logic is compiled and pushed to the CDN, ready to be run by a serverless compute process.

In the real time process:

1. An end-user performs an interaction (eg. hits the login button), initiating an HTTP request
2. The request is received by the CDN server, close to the user, and begins handling how to respond. If a Darwinium Step was deployed that matches the request, the corresponding serverless compute service (eg. Web Worker, Lambda Function) is kicked off in a separate thread.
3. If the Step includes instructions to inject attributes into the headers of the request, the serverless compute process will do so, before the request is forwarded to the origin server (business).
4. The origin server then handles the request, which now includes Darwinium insights within the headers to inform how to respond.
5. Response from the origin is sent back to the CDN.
6. If Darwinium Step includes logic to change the response, (for example changes to the body content like injecting profiling, adding Captcha and other dynamic content change), another serverless compute process will initiate in the CDN to do so, before sending the revised response back to the end-user.

How do I instruct Darwinium to enrich headers?

Attributes are mapped to be injected into headers from within the Data Mappings tab of the journey editor in the Darwinium Portal.

This is found by: Workflows (sidebar) > Click on .journey.yaml file > Click on Step > Data Mappings Tab.

The names and attributes to inject are defined by adding them to the Header Mappings.

(Note: The characters of header name need to be valid for HTTP request: so alphanumeric and _ - only)

Any attribute can be injected into the headers, but of particular interest:

For more details on Injection methodology, see Injection and Extraction Menu

API Call to Darwinium

Darwinium can also be called via API, and returns all data associated to a previous journey or interaction.

Any time prior:

0. A Darwinium API Step is defined in the Darwinium Portal. When deployed, the logic is pushed to the CDN, forming an API endpoint there.

In the real time process:

1. API call is made to the endpoint. The Darwinium identifier/journey_id of interest is included as a parameter.
2. The API call is received. The corresponding serverless compute service (eg. Web Worker, Lambda Function) is initiated to retrieve the data and run any additional logic that was defined.
3. The process will retrieve all data related to the identifier on the request and add it to the response back.
4. The response with Darwinium data is received back and can be used for decisioning.

A common design pattern is to return the Darwinium identifier and/or journey_id on a header at the time of the request, in anticipation of using it to make an API call later.

For more details, see articles within API Integration.