Custom Action


Once the custom integration is configured, it's possible to configure custom actions that will be associated to it. Click the Actions tab (1 - Figure 8) and then the Add action button (2 - Figure 8).

Figure 8 - Add Custom ActionFigure 8 - Add Custom Action

Figure 8 - Add Custom Action

An action can be a data dip, a data push, or simply a “ping” to a specific URI within the custom integration context.

Name (1 - Figure 9) and Description (2 - Figure 9) identify the action being configured.

The Relative path (3 - Figure 9) indicates the URI to be used inside the custom integration to obtain this information.

Figure 9 - Add Custom ActionFigure 9 - Add Custom Action

Figure 9 - Add Custom Action

When executing an action, the endpoint that will be invoked is the Base path configured in the Custom Integration concatenated with the Relative path of the action. The URL Preview (4 - Figure 10) will display the final result.

Figure 10 - Add Custom ActionFigure 10 - Add Custom Action

Figure 10 - Add Custom Action

In the Figure 9, the Relative path (3) contains a query parameter: request_id. The double curly brackets identify it as such. From the moment this parameter is added, it appears under the Path Parameters (5 - Figure 10) section, and it can be configured:

  • By default, the Display name (7 - Figure 10) is the same as the parameter name (displayed on Parameter (6)), but it can be changed.
  • By default, the Parameter type (8 - Figure 10) has the value string. However, this type must match the one that will be configured on the Studio Execute Action Component. You must adjust the parameter type to match the type that will be configured on the Studio Execute Action Component (otherwise the execution will fail even though the configuration seems successful).

It is also possible to configure the Inputs and Outputs (9 - Figure 10).


This is a configuration of the action in the format of schemas, so here you will not insert the values to be sent as input, nor the ones to be received as output.

The Input Schema (10 - Figure 10) represents the structure of the input body the action will receive when executed, and the Output Schema (11 - Figure 10) represents the structure of the output body the action will return when executed.

Each of these schemas is optional, and their definition highly depends on the action being defined. If it is a data dip (as per the example of Figure 7), usually only the Output schema is defined. If it is a data push, either just the Input schema is defined or both, depending on whether there is any interest in the response. If the action is simply a ping, for instance, none of the schemas is necessary.

A schema, be it for the input or the output, must always be a JSON with these fields:

  • Schema with value "".
  • "object" value.
  • title (must be a string).
  • properties (must be an object with the fields to be expected in the body when the action is executed).
  • required as an optional field (an array with the names of the properties that must be present in the body when the action is executed).


If a property named here is not present in the body during the execution, the execution fails.

The Output Schema (11) in Figure 10 is as follows (an Input Schema could be exactly the same, it all depends on the information that is important).

  "$schema": "", // this value must remain unchanged
  "type": "object",         // this value must remain unchanged
  "title": "Output",        // this value must remain unchanged (Input for the input schema)
  "required": [             // list of the properties that are required. All properties here listed must also be defined in the properties field
  "properties": {           // the properties that will be received in the output and that you want to match in Studio
    "id": {
      "type": "integer",    // the property "id" is an integer
      "title": "Request ID" //the description/name of the property "id" is "Request ID"
    "status": {
      "type": "string",
      "title": "Status of the request"

This schema means that when the action is executed, two properties are expected:

  • id (type integer).
  • status (type string).


Type and Title Fields

The name of the property must exactly match the field that will be in the body (in the execution). For each property, the type and title fields are mandatory.

Unlike the Output Schema, all the fields that may be received as input must be defined in the Input Schema. If they may not be always present, they must not be specified.

Here is more information on the types of fields that can be configured.

After saving, the action will be listed under the Actions tab (1 from Figure 11) of the custom integration page.

Figure 11 - Actions Listing Under the Actions TabFigure 11 - Actions Listing Under the Actions Tab

Figure 11 - Actions Listing Under the Actions Tab

By clicking Action (2 from Figure 1 - Action is just an example), you can access the View Action page (Figure 12). You can edit the action settings by clicking the Edit button, in the top right corner. You can also test the action and publish it (if it's a draft), as shown below.

Figure 12 - View Action PageFigure 12 - View Action Page

Figure 12 - View Action Page


Executing an Action outside Connections

Please note that if you are able to successfully execute an action on a product other than Connections (e.g. Postman), it does not mean the same configuration will work on Connections, as they are different products with different capabilities.

Did this page help you?