The Complete Guide to using Webhooks with Automator

As a business owner, you probably pay for multiple online services. You may even have several websites that you manage. Have you ever struggled to keep information in sync across your different accounts and sites? Wouldn’t it be amazing to hook all your separate services and websites on the web together?

In this post, we’ll explore a standard way of connecting things together on the web, quite appropriately called webhooks. We’ll discuss what they are, how they work, and how to use Uncanny Automator’s webhooks to set up automated workflows that span across all your services and websites.

Webhooks connect two sites together

If two applications or services support webhooks, you can connect them to each other. Zoom, for example, supports webhooks. If you install Uncanny Automator, your WordPress website also supports webhooks. This means that you can connect events that happen on your Zoom account with things that happen on your Automator powered WordPress website. To do that, there are a few key concepts that we need to understand about webhooks.

A webhook is an HTTP Request.

When you open a URL in our browser, what you are actually doing is sending an HTTP request of the GET type. When you submit a form, you send an HTTP request of the POST type. There are other types too.

A webhook is also an HTTP request but it is a request made by Site 1 to Site 2. Like any HTTP request, a webhook request needs a URL to call and the Request Method to use when making the request (GET/POST/etc).

1. Webhooks are event/activity announcements.

An individual webhook is usually associated with a single event (user activity). Whenever the event takes place, Site 1 calls (makes a request for) the webhook URL. In this sense, a webhook is an announcement for an event/activity. That’s why there are often Webhook Listeners on Site 2 that listen to the announcement.

2. Webhook URLs are always located on Site 2.

The Webhook URL (also called Webhook Endpoint) is always located on Site 2. Site 2 handles and processes the request just like it processes any other HTTP request.

3. Webhooks are like form submissions.

When an event takes place on Site 1, it calls a webhook URL. With this request, just like any HTTP request, Site 1 can also send information. This posting of information to a URL is similar to submitting a form. That’s why webhooks organize this information into key-value pairs, uncannily similar to form fields. When setting up webhooks, you can set up fields (also labeled parameters or values in some applications) that contain information about

• the event itself,
• the user who performed the event and
• other relevant and necessary information.

Forms most commonly use the POST HTTP method, so you’d find yourself setting the HTTP method of a webhook to POST too.

 

4. Webhook requests are always anonymous… therefore, they usually contain an email field.

Since a webhook connection is all about Site 1 making a request to Site 2, there is no user involved. So, even though webhooks can carry information about a user, as far as the receiver site is concerned, the webhook request always comes in from an anonymous source, never from a logged-in user’s session.

It is up to Site 2 to use the information in the webhook to identify an existing user in the system or create a new one. A universal identifier that is likely to be consistent across multiple websites is an email address. Other identifiers like the user’s ID and username will usually be different on different sites. That is why the information that travels along with a webhook usually contains a field for an email address. This is used to identify a user universally across sites.

Summary

Site 1 announces an event/activity in the form of an HTTP request to a specific URL on Site 2 and sends information relevant to the event/activity. This information is organized into fields. Since the request is anonymous, there is usually an email field added to help Site 2 identify the user. This process is similar to submitting a form and hence often uses the HTTP POST method.

Site 2 can now process and interpret the information and figure out what to do with it. One of the things that Site 2 will need to do is look for any user information among the incoming data. It can then decide whether the information is about an existing user or a new user and whether this new user needs to be registered.

With this understanding, we can now explore how to use Automator’s webhooks with an example where a user buys a WooCommerce product on one site and gets enrolled in a LearnDash course on another site.

Automator Webhook Trigger for Receiving Webhooks

Uncanny Automator contains a webhook trigger for incoming anonymous webhook requests for other sites. You can create an anonymous recipe with this trigger and use one of the incoming fields to select the user for subsequent actions.

In the images above, we have set up a recipe to act as an incoming webhook listener. This means that when any site calls the webhook URL https://automator.uncannycloud.com/wp-json/uap/v2/uap-10382-10383 with an email address, this recipe will listen to it. If the received email matches an existing user’s email, it will enroll the user into a specific LearnDash course.

Now, you can add this URL to an outgoing webhook to any site, service, or application that supports webhooks to send a user’s email address to https://automator.uncannycloud.com/wp-json/uap/v2/uap-10382-10383 and enroll them into the LearnDash course automatically.

Of course, you could choose to create a new user, if the email address does not match any user. You can also perform any of other available actions in place of, or in addition to, enrolling users into a LearnDash course.

Automator Webhook Action for sending Webhooks

Automator also has a webhook action to send Webhook requests to other sites. In any recipe, simply incorporate the webhook action to send information.

In this example, we’ve set up a recipe to send a webhook when a user purchases a specific product. What you might have noticed is that this action’s webhook URL is the same as the earlier example. So, if you set up the outgoing recipe on Site 1 and the incoming recipe on Site 2, this combination of recipes works to enroll a user on a specific LearnDash course on Site 2, when they purchase a specific WooCommerce product on Site 1!

Conclusion

As must be clear from the example above, webhooks are really powerful tools for creating workflows and passing data between websites. If you have Uncanny Automator installed on your WordPress site, you can link your site to any service that supports webhooks to create and manage all of your workflows in one place. You can even pass data between multiple WordPress websites.

Once your recipes and automations are all set up to pass data automatically, you can start making plans for how you’ll spend your extra time!

Let us know in the comments if you have already experienced the power of Uncanny Automator’s webhook triggers and actions in your recipes. Also, let us know about any interesting integrations that you’ve implemented with webhooks.