Use Variables and Data Sources

Silent Data [Oracle] can evaluate the sources and targets of a step by using variables.

Silent Data [Oracle] recognizes the variables if wrapped in curly brackets with a dollar symbol ($). See the example below:

// Example of variable syntax

${data.event.fee}

Also, in Silent Data [Oracle], it is possible to use three data sources: TRIGGER, STEPS, and SECRETS. Examples are below.

TRIGGER

All the data inside the payload of a trigger response are identified as TRIGGER.
The sub-attributes available for the TRIGGER are:

//Sub-attributes availabe for the TRIGGER
TRIGGER.caller
TRIGGER.data

Let's imagine the following payload as a response to the trigger:

// Example of trigger response

{
  "event":{
       "id": "3geys64tbtmwe8yr",
       "value": "success",
       }
 }

To use the id of the data object returned from the trigger of Silent Data [Oracle], the user can select:

// Syntax of variable applied at the response of the trigger. It returns the value of the "id":"3geys64tbtmwe8yr"

${TRIGGER.data.event.id} 

If the trigger response has a list inside the response, like the following example:

//Example of a response with a list of events

{
    "events":[
        {
           "id": "3geys64tbtmwe8yr",
           "value": "3000",
           "currency":"USD",
       },
       {
            "id": "3geys64tbtmw9iut6",
           "value": "2000",
           "currency":"USD",
       },
       }
            "id": "3geys64tbtmw90oyr",
           "value": "5000",
           "currency":"USD",
       }
    ]
 }

To use the id of the first item of the list of the data object returned from the trigger, the user can select:

// Syntax of variable applied at the response of the trigger. It returns the value of the first ID of the list "id":"3geys64tbtmwe8yr"

${TRIGGER.data.events[0].id} 

For the trigger, we can also retrieve the caller, which is an IP address in the webhook calls, and a Smart Contract address for the Smart contract trigger. This is the syntax:

// Syntax of the variable to returns the caller of the Trigger

${TRIGGER.caller}

STEPS

To use the steps, the user can define the step from which to consider the response.
The sub-attributes available for the STEPS are:

//Sub-attributes availabe for the STEPS
STEPS.data
STEPS.status

Request Step
For request steps, the endpoint can be simple or with a concatenation of variables:

//The endpoint can be defined in the following way :
endpoint: https://api.stripe.com/v1/dyr784jtbh830jhd

//The endpoint can be defined in the following way :
endpoint: https://api.stripe.com/v1/${TRIGGER.data.id}

It is also possible to use previous request steps payload data:

//The endpoint can be defined in the following way :
endpoint: https://api.stripe.com/v1/${STEP[1].data.id}

Attestation Step
For attestation steps, the source and the target can use variables from the trigger, from previous steps, or simple values:

//Attestation step with trigger variable
 "conditions": [
                    {
                        "source": "${TRIGGER.data.value}",
                        "operator": "==",
                        "target": "success"
                    }
                ]

//Attestation step with previous step variable
 "conditions": [
                    {
                        "source": "${STEPS[1].data.value}",
                        "operator": "==",
                        "target": "success"
                    }
                ]

Let's consider 2 steps configured as below:

The first request step is to access data through an API. The API in the example retrieves the balance transaction with the given ID.
The second step is an attestation rule to check that the currency of the transaction is "usd".

This is the response we expect from the API:

//Example response of Stripe API for balance transaction
{
  "id": "txn_1032Rp2eZvKYlo2CpErRBj09",
  "object": "balance_transaction",
  "amount": 400,
  "available_on": 1386374400,
  "created": 1385853205,
  "currency": "usd",
  "description": "Charge for test@example.com",
  "exchange_rate": null,
  "fee": 42,
  "fee_details": [
    {
      "amount": 42,
      "application": null,
      "currency": "usd",
      "description": "Stripe processing fees",
      "type": "stripe_fee"
    }
  ],
  "net": 358,
  "reporting_category": "charge",
  "source": "ch_1032Rp2eZvKYlo2Cv6jPGmkF",
  "status": "available",
  "type": "charge"
}

The syntax from the picture above:

//Syntax to return the currency (usd) from the Stripe API for balance transaction

${STEPS[1].data.currency}

For the steps, if you are more interested in the status of an API request, the variable to use is the following:

//Syntax to return the status of a step

${STEPS[n].status}

Replacing the "n" with the number of the step you are interested in. The statuses available are the standard statuses of an HTTP request.
Please look at the top of the box to know the exact number of the STEP.

In this case, Silent Data [Oracle] already knows what type to expect as a target.

SECRETS

In the example above, the Stripe API is private, so the user needs to add a key to access it.

In Silent Data [Oracle], it is possible to save the secrets and use them for the authorization instructions of the private APIs.
The sub-attributes availabe for the SECRETS is:

//Sub-attributes availabe for the SECRETS
SECRETS.{secrets_name}

From the image above, it is visible how to use the SECRETS in the header of a request. The secret with the name STRIPE_KEY is used in the API call.

//Syntax to add the authorization in the header of the request for a private API

{"Authorization":"Bearer ${SECRETS.STRIPE_KEY}"}