SRT configuration

Within the API Reference page, several methods are dedicated to managing SRT transformers.

Let's briefly explore the components involved and how to create them. In subsequent articles, we will provide detailed examples of creating SRT transformers and demonstrate sample body requests for generating email messages utilizing the created SRT transformers.

To create an SRT transformer, you need to specify the name and designate the config type. These two parameters are essential in defining the transformer and its configuration.

{
   name: String,
   config: JSON
}

Below are the descriptions of the possible fields:

Parameter	Required	Description
`name`	Mandatory	This field refers to the name of the SRT rule. It provides a distinctive identifier for the rule, allowing you to easily reference and manage it within your system. Giving meaningful and descriptive names to your SRT rules can help enhance clarity and organization when working with multiple rules.
`config`	Mandatory	This field defines the configuration type for the SRT transformer. It specifies the format or structure of the transformer's configuration data. JSON description { start: [ { id: String } ], repeatable: [ { id: String, rules: { enum } } ], tail: [ { id: String } ] } where: start, repeatable, tail — These are the section names where you define the rules for the layout of modules in your email. id — This refers to the Unique Identifier (UID) of the module that has been saved to the Library. It helps identify and reference the specific module you want to use. rules — This parameter denotes the name of the conditional rule applied to a particular module. You can apply different conditional rules to modules based on your requirements. Please refer to the Resources documentation to access the detailed list of conditional rules that can be applied to modules in your email template.

📘
Understanding how data is distributed among modules using the SRT transformer is crucial. The data objects from the dataSources are sequentially distributed from top to bottom into modules based on the configuration specified in the SRT transformer.
In cases where we work with static modules that should not receive any data from your feed, we can include the skipValue:true parameter in the configuration for those modules. By doing so, the data object from the dataSources will be applied to the subsequent module, ensuring the current module does not utilize that particular data object.
It is important to pay attention to this behavior in the upcoming articles that include samples, as it will further clarify the process and usage of the SRT transformer.

In the next articles, let's explore some samples of SRT transformers and accompanying body requests for generating email messages.