Parameters in Custom Integrations

Let's explore how to create a parameter.

1. In the API request, we see an API key being used directly in the body of the URL. We want to convert this into a parameter. To achieve this, we'll replace the key with a macro.

2. Next, save the configuration and refresh the page. Notice that the parameter now appears in the list of parameters. Let's enter its value and save the configuration again. The saved value should now be visible in the parameters section.

3. Returning to the URL, we see a domain name. Since this is a unique identifier for the client, it also needs to be included as a parameter.

With these steps, all necessary parameters have been created.

Motivation: Store sensitive information in a specifically designated element

For the integration to function, an authorization token and other customer specific authentication parameters are required.

Our server needs to know where the sensitive information is in order to:

• keep it in a hardware secured storage.
• delete it when the config is shared or deleted.

To facilitate this, we use the parameters element.

Instead of hardcoding the token, we rewrite the configuration as follows:

"headers": {
  "Authorization": "Bearer {$token}",
  "accept": "application/json"
}

When Conduit detects the curly braces {$ }, it prompts the user to provide a value for the “token” parameter.

Parameters can be utilized anywhere in the configuration, both in headers and URLs.

"headers": {
 "Authorization": "Bearer {$token}",
 "accept": "application/json"
}

or

"url": "https://{$SUBDOMAIN}.flowlu.com/api/v1/module/crm/source/list?api_key={$APIKEY}"

Stored Values

Stored values for parameters are child elements of the “parameters” element, represented as name:value pairs. For example, as shown in the screenshot below:

"parameters": {
 "token": "QnlXSExP",
 "SUBDOMAIN": "mycompany",
}

NOTE: The integration developer is responsible for creating these parameters and selecting appropriate names and values for testing.

Runtime

During the execution of the request our server detects curly brackets. In this example, the server finds {$token} and replaces it with the value "QnlXSExP" founded in the “parameters” section, resulting in:

"headers": {
 "Authorization": "Bearer QnlXSExP",
 "accept": "application/json"
}

Why use the "Bearer {$token}" parameter instead of directly writing "Bearer QnlXSExP"? The end user does not edit the JSON directly. Our server shows a UI where the end user enters a token, and the server writes the value into the JSON.