Note: Using Utility Connectors counts toward your overall Connector and Task Usage.
Purpose #
The Generic Webhook Utility Connector provides the following Connector Methods, allowing you to make common HTTP requests to remote systems, as well as use Webhooks:
- HTTP Methods:
- DELETE
- GET
- PATCH
- POST
- PUT
- Webhooks:
- Synchronous Response
- Webhook
- Webhook (IP Filtered)
Note: While the Generic Webhook Connector and its Methods could provide a simply way to get started when there isn’t a dedicated Connector for a system, we do recommend using a fully featured Connector instead, as it can be setup to work exactly as that system expects.
As with all connectors, the Generic Webhook Utility Connector can be added multiple times. This allows the Connector to be setup and named appropriately for several use-cases.
The Connector’s Webhook and Webhook (IP Filtered) Methods enable you to use them as a way to trigger a Cycle from an inbound HTTP POST request. This is useful if an application connector does not include a method specific to that requirement.
Each instance of these Webhook Methods uses a unique URL to which an HTTP POST request can be made. You will need to define request body fields as Custom Fields when setting up the Connector.
Read more about Webhooks in Cyclr
Passing Control between Cycles #
The Generic Webhook Utility Connector can be used to link Cycles together. For example, a step in Cycle 1 can make an HTTP POST to a Webhook that has been set up as a trigger to start Cycle 2.
Note: While the Generic Webhook Connector can be used for this, the Linking Connectivity Tool is intended to be used for this purpose so is the recommended way.
This linking of Cycles might be done when an integration is large and complex, and splitting it into smaller units will improve maintainability. It might also be done when the same processing needs to be run in a number of situations and linking is preferable to duplicating the same sequence of steps in multiple Cycles.
To set this up you will need to add custom fields to the Generic Webhook connector for the information that will be passed between the Cycles (see below). The same fields will need to be added to both the POST in the HTTP Methods section and to the Webhook in the Webhooks section of the Connector Settings.
You should then build both of the Templates (or Cycles) before making the linkage. When you add the Webhook trigger to Cycle 2 you will be given the URL it will use to listen for inbound requests. This should be copied and entered as the URL Field in Step Setup of the POST Step in Cycle 1.
When testing or running this kind of ‘linked Cycles’ structure you must start Cycle 2 before Cycle 1. If you do not do this there is a danger that the webhook receiver will not be active before the first POST is made.
In this example, 2 Cycles have been used but the same procedure can be set up to chain together a whole series of Cycles.
Filter webhook requests by IP address #
The Generic Webhook Connector has the ability to filter incoming webhook requests by IP address.
To use this feature, set the Allowed IP Addresses parameter within the Connector’s Setup and then use the Webhooks > Webhook (IP Filtered) Method in your integrations.
Only requests made from those IP addresses will be accepted by the Webhooks > Webhook (IP Filtered) Method.
Note: The original Webhook Method is unaffected and will continue to receive and process all requests.
Warning: If the Allowed IP Addresses parameter is left blank, all incoming webhook requests will be rejected by your Webhook (IP Filtered) Steps.
The Allowed IP Addresses parameter can be changed at any time by accessing the Connector Setup for an already installed Connector. Any changes will be picked up immediately and Cycles containing Webhooks > Webhook (IP Filtered) Steps do not need to be restarted to reflect the changes.