Knowledge Base

Introduction

The Ligantic Platform's Integration HTTP Node provides a powerful way to integrate external services into your Flows. This node allows you to configure various aspects of the API call, including the HTTP method, URL, headers, search parameters, and request body. The results of the integration can then be further utilised within your Flow, enabling you to seamlessly incorporate external data and functionality into your Ligantic experiences.

But wait, what is a HTTP Integration?

HTTP integrations, also known as API calls, are a powerful way to connect different software systems and automate workflows. APIs allow your applications to securely exchange data and functionality with other tools, without the need for manual data entry or complex integrations. The four main HTTP methods - GET, POST, PATCH, and DELETE - enable you to retrieve information, create new data, update existing records, and remove data as needed to streamline your processes.

That's where Ligantic's workflow automation platform really shines. Our no-code interface makes it easy for anyone to build and configure API integrations, without needing to write any code. Simply select the API endpoint you want to connect to, choose the HTTP method, and map the data fields - Ligantic handles the backend complexity so you can focus on designing efficient, automated Flows. Whether you need to sync data between your sales, marketing, and support tools, or trigger actions across your entire software ecosystem, Ligantic's API integration capabilities open up a world of possibilities. You can unlock new levels of efficiency and innovation by tapping into the full power of API-driven Flow automation.

Integration HTTP Node

The Integration HTTP Node allows you to make http requests from within your Flows.

Incoming Node Edges

• Trigger: This is where the control flow triggers this Node.
• Dynamic Data Inputs: These are dynamic and optional incoming Node Edges that are dependent on the configured options within the Node and whether they're set as Dynamic. Dynamic data inputs need to be fed into the Node from other areas in the Flow.
  • Dynamic URL: Expects a string value as an input that contains a valid URL.
  • Dynamic Header Values: Expects either string or number values as the value to correspond with the named Key set in the internal Node Configuration.
  • Dynamic Search Param Values: Expects either string or number values as the value to correspond with the named Key set in the internal Node Configuration.
  • Dynamic Body: Expects either a text or structured JSON object value based on the internal Node Configuration.

Node Configuration

• Method: Configure the HTTP method to be used for the http integration. You can choose from:
  • GET
  • POST
  • PATCH
  • DELETE
• URL: Configure the target URL. The static text field can be filled in or a dynamic type configured. If the Dynamic? configuration is set it will create a corresponding Incoming Node Edge.
• Headers: Headers provide important context and metadata about the HTTP integration, which can be crucial for successful API integrations and ensuring the requests are properly formatted and authenticated.
  • You can keep the Headers configuration disabled if no headers are needed.
  • Once enabled, you can configure one or many key value pairs. Keys are set as a named text input. Values can be statically set or configured as a dynamic Incoming Node Edge that takes in string or number inputs.

Examples showing: 1) No Headers enabled. 2) One static Header enabled. 3) One dynamic Header enabled. 4) Multiple dynamic Headers enabled.

• Search Params: Search parameters (also known as query parameters) are additional information that can be included in a HTTP request to filter, sort, or otherwise modify the response data. Setting search params allows you to retrieve only the most relevant information needed for your specific use case.
  • You can keep the Search Params configuration disabled if no search parameters are needed.
  • Once enabled, you can configure one or many key value pairs. Keys are set as a named text input. Values can be statically set or configured as a dynamic Incoming Node Edge that takes in string or number inputs (similar to the configuration shown for Headers above).
• Body: For HTTP integrations the "body" refers to the main content or payload that is included in the HTTP request or response. The body is the part of the message that contains the data being sent or received, as opposed to the headers which contain metadata about the request or response.
  • You cannot enable a Body when the GET Method is configured.
  • You can keep the Body configuration disabled if no body or payload is needed.
  • Once enabled, you can configure the Body Content Type. You can select Text or JSON. Body values can be statically set or configured as a dynamic Incoming Node Edge that takes in the configured input type.
  • You can create simple or complex Body Schema configurations using the JSON Content Type configuration settings to correctly send the appropriate data to the integration. Add one or many properties, name them, select the appropriate data type, and choose whether they are required.

Examples showing: 1) No Body enabled 2) Text content type with static body value. 3) Text content type with dynamic body value. 4) JSON content type with static body value. 5) JSON content type with dynamic body value

• Result: Configure the expected result definition that will be returned out of the Outgoing Node Edge. The default configuration is a string named "result" that is required. You can configure the result type to be:
  • Entity: The result definition will define an object that matches the data shape of the chosen Schema.
  • String: Expects a string result.
  • Number: Expects a string result.
  • Boolean: Expects a boolean result.
  • Date: Expects a date result. If Include Time? is checked, expects a dateTime result.
  • Array: Expects an array of the configured data type as a result.
  • Object: The result definition can be a simple or complex object built using the add property configuration options. Add one or many properties to the Object, name them, select the appropriate data type, and choose whether they are required.

Outgoing Node Edges

• Error: This is for when any error state has been returned from the Integration HTTP Node. You can handle the error state gracefully from this outgoing Node Edge.
• Success: This is for when the integration completes the execution successfully.
• Status: This is where the response code for the integration is returned. These response codes provide a numerical status of the request and can be leveraged to understand and troubleshoot the integration in the execution logs. Common response codes are;
  • 200 - Successful request
  • 400 - Bad request, usually due to invalid data or parameters
  • 401 - Unauthorised, the request requires authentication
  • 404 - Resource not found
  • 500 - Internal server error, an issue on the external system
• Results: This dynamic Outgoing Node Edge follows the internal configuration of the Result and captures the response from the Integration.

By configuring these settings, you can seamlessly integrate external services into your Ligantic Flows, allowing you to leverage the power of the Ligantic Platform to create more robust and dynamic experiences.