Configuring conditional API orchestration
The Demyst platform allows for conditional logic to be incorporated in a Data API to only call upstream sources when specific conditions are met
About this guide
The Demyst Platform allows for conditional logic to be incorporated in a Data API to only call upstream sources when specific conditions are met. In this guide you will learn to set up the configuration with such conditional logic.
Steps
1 - Create a new Data API
Navigate to https://demyst.com/app/create-api and include the Connector that you want to include in your new Data API.
2 - Configure connector precondition - when
when
Connections with a when expression are only executed if the expression evaluates. This allows you to optimise for specific metrics such as response time, performance or costs by only calling upstream sources when required.
Add your low code JSON snippet to the configuration section of the API.
# Only call the Seon fraud connector if the Domain from email Connector failed
{
"providers": {
"domain_from_email": {
"version": "$latest"
},
"seon_fraud_v2": {
"version": "$latest",
"when": {
"domain_from_email": "$failed"
}
}
}
}
That configuration can be saved in the Data API directly.
Your API is now configured.
3 - Test your new Data API
Test your new Data API with the sandbox interface or programmatically.
Additional Details
Syntax
- A JSON object
- An arbitrary expression on a connector or attribute level, identical to those options in refine
-
- A JSON
string
— a path to an attribute.
The custom attribute will contain the value at this path. - A JSON
object
from connector to a function
Example
{ "domain_from_email": "$isMatch" }
Returns
true
if the connector function matches - A JSON
object
from connector to a function
Example
{ "seon_fraud_v2.data.fraud_score": { "$gte": 0.5 }}
Returns
true
if the connector function matches
- A JSON
Example scenario
Failover: Often one provider will not have all the data that you need. In such a situation (for eg. credit checks where bureaus may have thin coverage across a region), when a Connector fails to return a response, Demyst empowers you to call the next possible provider without adding any extra steps to your workflow process.
Refresh by precondition: You may want to be cost-efficient and only refresh your data when a certain time threshold has been exceeded. In the case of KYB checks, for example, when the refresh date for cached data is beyond a threshold, you can use the precondition configuration to route a live call to the registry.
Payload example
Here are some examples of precondition-based configurations being implemented.
Refer to the Functions on attributes and Functions on connectors pages for more DSL definitions that may be useful in this journey.
#Only call Neutrino when Zero Bounce has no match or an Invalid status.
{
"providers": {
"zero_bounce": {
"version": "$latest"
},
"neutrino_email_validate": {
"version": "$latest",
"when": {
"$or": [
{
"zero_bounce": "$noMatch"
},
{
"zero_bounce.status": {
"$eq": "invalid"
}
}
]
}
}
}
}
# Only call the Hazardhub connector when country, state, city, post_code and street are all present
# from the Infutor connector call
{
"providers": {
"hosted_infutor_auto_profiles": {
"version": "$latest"
},
"hazardhub_risks_and_enhanced_property2": {
"version": "$latest",
"when": {
"$and": [
{
"hosted_infutor_auto_profiles.results[0].country": "$nonEmpty"
},
{
"hosted_infutor_auto_profiles.results[0].state": "$nonEmpty"
},
{
"hosted_infutor_auto_profiles.results[0].city": "$nonEmpty"
},
{
"hosted_infutor_auto_profiles.results[0].post_code": "$nonEmpty"
},
{
"hosted_infutor_auto_profiles.results[0].street": "$nonEmpty"
}
]
},
"inputs": {
"country": "hosted_infutor_auto_profiles.results[0].country",
"state": "hosted_infutor_auto_profiles.results[0].state",
"city": "hosted_infutor_auto_profiles.results[0].city",
"post_code": "hosted_infutor_auto_profiles.results[0].post_code",
"street": "hosted_infutor_auto_profiles.results[0].street"
}
}
}
}
Updated about 1 year ago