Sending data is normal if not a fundamental part of everyday life and there are numerous ways data can be sent from one place to another. Typically, this data-sharing process involves integrations between several different APIs for a variety of SaaS applications. There is however an alternative method and this involves building integrations and utilising the power of a webhook.
What is a webhook?
A webhook is used for event-driven integrations and is one of the many ways applications can communicate with each other. They allow you to send real-time data from one system to another when a given event occurs.
As a result of this notifications can be generated in an application after an event occurs. For instance, when a form fill has been completed or a newsletter sign-up has been made, this data or event triggers an integration workflow in action.
These notifications are sent to a webhook receivable URL, which includes a range of data set by the sending application. This type of data can be extremely simple. For example, checking that an action has been run, or POSTing data in JSON, XML or form data formats to be unpackaged and made use of by the receiving application.
How is a webhook different from an API?
Webhooks and APIs (application programming interfaces) have much in common. Especially the fact that they are used for applications to communicate. However, the main difference is that an API requires you to make a request for data, while a webhook notifies you when a certain event takes place.
This method of sending data is an event-driven push action, whereas typical APIs will request data via a GET request on a user’s request or timed interval. For instance, when an event occurs it triggers the webhook integration into action.
What is a real-world webhook example?
A practical example of a webhook integration in action is receiving a notification when a user has initiated a chat or filled out a form. To do this a preset webhook URL would be added to the form. This means the data can be sent to the receiving application.
The submitted data is added and tracked in a CRM or marketing system which helps your relevant teams stay up to date with customer accounts or communication preferences.
The webhook in the integration workflow would include all of the fields in the form, encapsulating them in JSON/XML format with the users’ responses when the send button is clicked. This would also be the trigger to send the data to the Webhook URL.
An example of a received Webhook packet would look like this:
"your-name": "Bill Gates",
"your-subject": "I’d like to find out more",
"your-message": "Hi there, I’d like to learn more about your product. Can we please arrange a time to talk. Thanks, Bill",
The receiving application would take this POST request data and map it to the relevant fields in their SaaS platform.
Event-driven integrations typically use webhooks with the POST function to trigger an integration workflow. This webhook integration supplies the initial data to run the integration. This method is used to create “real-time” integrations. However, while the time to trigger the webhook is near instantaneous, any latency in the sending and receiving applications will inevitably add to the delivery time.
The integration will have to be set up so that the receiving application already knows what fields it is receiving. It can then make use of the incoming data properly.
Setting up event-driven integrations
Setting up the integration can vary between applications. In some cases, users will need to manually add the webhook URL. This is so the data is sent to a management screen in the sending application.
However, many applications include the ability to POST webhooks directly to their backend through their API.
What are two requirements for an application to communicate with a webhook provider?
In order to receive a notification from a webhook platform, the application must meet certain requirements:
Firstly, in order to receive a HTTP POST request the application must always be running to ensure the data can be captured. Secondly, on the webhook provider so that the provider knows where to send a notification when target events occur.
Using Webhooks in Cyclr
Cyclr can provide you with the right tools to build these types of integrations.
To start your workflow you’ll need a webhook step, this will either trigger the workflow when the URL is triggered in Cyclr. Alternatively, it will supply the initial data to use in the integration and map into other applications
You can then build out the workflow like you would a polling-based integration. Use the initial data to either directly map into another application, or use it to trigger other steps and processes in your workflow.
Take a look at the video above to see how you can use the Cyclr Generic Webhook to connect to third-party SaaS applications.
How to create a webhook URL
While many of the connectors in Cyclr contain webhook steps, you can also use our Generic Webhook Connector.
This connector has multiple uses; the most common use is for receiving data (providing you with a URL to place in your triggering application as well as the ability to auto-discover the fields being sent), but you also have steps available to POST data.
Webhook Steps in Cyclr are signified by the black line on the step’s left border.
How to POST data using Webhooks
POSTing data using the Generic Webhook allows you to define a URL to any external system. Then build out which fields you want to include in the data packet.
You can use this to include any of the data within the workflow, allowing you to combine data from multiple sources.