Define the Data Transformation Schemas

Use the Synchronization tab to convert a JSON object from the third party system to an JSON object and vice-versa. Each object must contain a brief description, the module type that will be synced, and the push or pull action. Push is for sending data to the third party system and Pull is for receiving data.

In addition pre and/or post synchronization actions can be enabled for each synchronization action. These actions give developers the ability to retrieve data (i.e synchronization token) from the external API system or sync a different module prior to or after the actual synchronization. The data retrieved from an external API system can be set as a header or as a property in the module that will be synced.

Push and Pull Methods

There are three possible push paths: createupdate and delete. Pull can have two paths: batchRead and read. For each path, the API URL and the verb must be specified  as string with the format “ApiUrl/verb”. A Push or Pull method includes paths, the transformation for each path, Pre/Post synchronization actions and/or statements.


SchemasTransformer must contain one transformation for each path. If the schema is for a request, the name should be {schema}Request. If the schema is for a response the name should be {schema}Response.

The value of the transformation is a JSON schema string using JUST Library. JUST Stands for “JSON Under Simple Transformation” and this library enables the transformation of JSON documents using a very simple transformation language. For more details, please check

This example is using a simple transformation to convert a BSS invoice to a 3party system invoice.

Pre/Post Synchronization actions 

Pre/Post Synchronization actions are defined as an object preSynchronizationAction/postSynchronizationAction and can have the following properties:

  • Type: The type of action (ApiPath, ApiSynchronization)
  • Path: The URL path for the defined action (URL or the name of transformation object that will be synced)
  • Schema
    • If schema is used to store a value in header then type, header and headerValue are required.
    • If schema is used to store a value in body then type and variable name are required.
  • In: where the value should be saved. (Valid values: Body, Header)

See an example of preSynchronizationAction below:

The batchRead operation triggers the read operation for each of the received items, therefore the read operation is required for batchRead to work.


For each push/pull event several statements can be enabled. Statements are executed prior to synchronization for push events and after Synchronization for pull events.

Statements have the following properties:

  • Description: A brief description of the statement
  • Priority: Priority of the statement (Valid values: Lowest, Low, Normal, High, Highest)
  • Conditions: An object that contain all the rules of the statement
  • OnFailure: The action what will be triggered if conditions inside statement are false (value: StopProcess)
  • OnSuccess: The action what will be triggered if conditions inside statement are true (value: StopProcess)

Conditions / Rules

These elements consist from the following properties:

  • Type: The type of condition/rule. (Combination, Condition)
  • LogicalExpression: Required when type is Combination. The logical expression check between the rules (Valid values: OR, AND)
  • Rules: Consists of an array of rules
  • Variable *Required when type is Condition. The Variable that will be checked against the given value
  • Operator *Required when type is Condition. The type of operator that will be used for the condition (Valid values: NotEqual, Equal, LessThan, LessOrEqualThan, GreaterThan, GreaterOrEqualThan, Like, StartsWith, EndsWith)
  • Value: Required when type is Condition. The value that will determine the result of the condition

Example of statement for Account Type and another combination of rules.

Conditions and rules can contain “N number of times” of nested conditions and rules