Updated on by Hayley Brown
Using automation technologies to build integrations is a useful solution for expanding your product integration capabilities. As well as creating internal automated workflows to streamline processes.
When building your integration solutions you can use webhooks. These are powerful, event-driven triggers that can provide extra functionality and customisation to your automated workflows. So, let’s see what a webhook is, some generic webhook examples, and how you’d set one up.
Defining a Webhook
A webhook has an event-driven architecture and is one of the few ways web applications can communicate with each other. The webhook allows you to send real-time data from one application to another when a given event occurs. Rather than sending repeated requests for new events.
Jeff Lindsay, an early conceptualise of webhooks defines them as “an architectural pattern for web developers to provide user-defined callbacks over HTTP in their applications.”
The difference between an API and a webhook is that an API requires you to make a request for data. A webhook, on the other hand, notifies you when certain events take place. Implementing a webhook simply requires setting up a single POST request on the sending end. This will send a packet of data, a form fill, for example, to a webhook URL. The webhook receiver can then process the packet of data in a range of ways.
For example; a webhook is triggered when a user has initiated a chat or filled out a form on your website. This submitted data is added and tracked in a CRM or marketing system using the webhooks packet data.
Webhook data is sent into one or multiple systems when used in conjunction with an integrated workflow. The workflow automation is triggered when an event happens in your internal system, for example, a restaurant reservation. This starts the integration workflow process across as many platforms and processes as you may need in real-time.
What is a Generic Webhook?
A generic webhook listens for messages and is then triggered based on the payload. They can trigger integrations through an external webhook action, which provides the typical HTTP Methods – DELETE, GET, PATCH, POST, PUT. This allows you to make HTTP requests towards remote systems.
The Utility Connector also provides a webhook method. This can be used to trigger a workflow from an inbound HTTP POST request. Useful if an application connector does not include a method specific to that requirement.
Each instance of the webhook method uses a unique URL to which a POST request can be made. You will need to define the request body fields as custom fields when setting up the connector. As with all of our connectors, the generic webhook utility connector can be added multiple times. This allows the connector to be set up and named appropriately for each use case.
How can webhooks be implemented in your workflows?
You’ll be able to implement the generic webhook in your Cyclr workflows to link two or more integration workflows together. For example, a step in workflow 1 can make an HTTP POST to a webhook that has been set up as a trigger to start workflow 2.
This linking of workflows might be done when integration is large and complex. It is helpful to split it into smaller units as this will improve maintainability. It might also be done when the same processing needs to be run in a number of situations. Then linking is preferable to duplicating the same sequence of steps in multiple workflows.
Generic Webhook Setup with Cyclr
To set this up in your Cyclr workflow you will need to add custom fields to the generic webhook connector. This is the information that will be passed between the workflows. The same fields will need to be added to both the ‘POST’ in the HTTP methods section. Then to the ‘Webhook’ in the webhooks section of the connector settings.
You should build both of your Cyclr workflows before making the linkage. When you add the webhook trigger to workflow 2 you will be given the URL. It will use the URL to listen for inbound requests. This should be copied and entered as the URL field in step setup of the POST step in workflow 1.
When testing or running this kind of ‘linked workflows’ structure you must start workflow 2 before workflow 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, we’ve mentioned two workflows which have used the same procedure but can be set up to chain together a whole series of workflows.
Other examples and benefits of a Generic Webhook
Webhooks are versatile and can be used as the first step in integration. They can be used as a way to receive data for processing, but they can also be used part-way through an integration. Providing a way to hold a transaction until ready to proceed.
Using a generic webhook in your workflows is an excellent way to improve integration efficiency with events and data posted in real time. They are a widely used and popular type of API, which is highlighted by GitHub. They emphasise webhooks’ freshness of data, the efficiency of communication and infrastructure costs.