API Call

Triggers an API Call in which you can pass parameters and payload to any system. The API responses will be returned as step output which is available under the data hub for further usage in the workflow.

Options

1. Choose System

2. Choose API

3. Choose Credentials

4. Provide API Information

Choose System

Search and select the target system from the list of private and public systems available under the current project as shown in the below image.

Choose API

After selecting the target system, the list of available active APIs of the selected system will be seen as shown in the below image. This can be managed in the API Manager.

Choose Credential

After selecting the target API, you have to choose or add the credentials to connect to the target system.

Here you can also test the credentials before selecting it, using the option Test with Fresh token.

API Call action is allowed to save only after selecting the System, Api and Credentials

API Information

Payload

API Request Body. This section allows the user to provide payload and also the ability to modify using Mapping & Modifiers and Preprocessor. The final payload will be sent while making the API request.

• Payload - Request Body. Information is sent along with the API call. You can provide data directly to the payload or select the data of previous steps from the data hub.

• Total Records - Number of records received/created using the API call. You can provide an integer value directly or select the length of data from previous steps using the data hub.

  • Mapping & Modifiers - Provides the ability to get mappings from the user and format data before calling destination API.

    • Data from the source fields are mapped to the associated destination fields and then formatted using Modifiers.

    • Payload is considered as Source Data.

    • For more details on how to create a mapping, navigate to Mapping and Modifiers

    
• Preprocessor - Provides the ability to modify the payload before making an api call. Use the code editor to modify the data.

Payload - Order of Execution

Payload ➡️ Mapping & Modifiers ➡️ Preprocessor

The initial payload will be modified in Mapping & Modifiers. The mapped payload will be modified in Preprocessor. If mapping is not configured, the initial payload will be modified in the Preprocessor.

The order cannot be changed. If payload modification is not needed, Mapping & Modifiers and Preprocessor can be skipped.

Response Validation

Users can set conditions to validate the API response. If the condition is met, it follows the successful workflow path; if not, it takes the failure path. Conditions can include checking if the API is successful using the status code or ensuring it contains data, among other business-specific criteria.

By default, each API call includes a condition to check if it's successful using the status code, but users can modify this condition using the condition builder to better suit their needs. This ensures flexibility and adaptability in response validation.

For some systems, the successful API response status code is not just 200. It may return 201 too. In such cases, you can modify the condition builder to use the "in" condition from the dropdown and provide values as a list. Example: [200, 201]

Advanced Options

The following are the other additional parameters which you can provide to make an API call.

• Headers - Request Headers. Example: {"Accept": "application/json"}

• Files - Upload one or many file contents. Example: [('file', ('foo.csv', "hello,there,csv,data")), ('file',('bar.txt', "this is a file content"))]

• URL Arguments - Arguments used in a dynamic URL.

  • Example Use Case:

    API URL: /api/customer/{customer_id}/fetch

    URL Argument: {"customer_id":"2"}

    Formatted URL: /api/customer/2/fetch

    In this case, customer_id is replaced with the number 2.

• Parameters - Request parameters

  • Example Use Case:

    API URL: api/customer/get/?format={format}

    Query Params: {"format":"json"}

    Formatted URL: api/customer/get/?format=json

    Here, format = json will be the query parameters.

• Override Timeout - To override the timeout at the flow level.

  • To override the API manager timeout at the Flow level.

    • Choose - Yes/No from the drop-down list. Yes - Override the timeout based on the read and connect values mentioned here. No - Do not override the timeout based on read and connect values mentioned here

    • "Connect" refers to the maximum allowed time for a DCKAP Integrator to establish communication with the system to which the API call is made.

    • "Read" refers to the maximum allowed time for the system to respond back to the DCKAP Integrator.

For XML Payload (Examples)

Plain request

{'plain_request': {'key1':'value1','key2':'value2'}}

Not a plain request

{'body':{'key1':'value1','key2':'value2'}}

Use keywords(DYNAMIC_TOKEN, GET_FROM_CREDENTIALS) to fetch and pass the respective dynamic information in headers and payload.

• DCKAP Integrator accepts API responses in JSON, CSV and Text formats.

• API Call action also has the facility to add headers from Flows.

To add additional envelope namespace

Along with the above request, add another key “envelope_namespace” to add additional namespace with default namespace

XML Request Body

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:enterprise.soap.sforce.com">
   <soapenv:Header>
   </soapenv:Header>
   <soapenv:Body>
      <urn:login>
         <urn:username>[e-mail]</urn:username>
         <urn:password>user1@123</urn:password>
      </urn:login>
   </soapenv:Body>
</soapenv:Envelope>

Converted JSON request Body

{
    "envelope_namespace": "xmlns:urn='urn:enterprise.soap.sforce.com'",
    "body": {
        "urn:login": {
            "urn:username": "[e-mail]", 
            "urn:password": "user1@123"
        }
    }
}