Automation is a powerful tool. With some foresight and a little elbow grease, you can save hours, days, or even months of work by strategically automating repetitive tasks. What makes automation particularly beneficial is that it eliminates manual interaction with multiple systems.
Rather than manually uploading data to an event response system or notifying key support personnel of an incident, tying these tasks together through automation can reduce critical time and help resolve problems faster and more efficiently. But, before we can fill in the gaps between all of the platforms we are responsible for, we first need to understand how data moves around on the web and how we can use that process to our advantage.
How Automation Works
To begin automation, we first have to understand how data gets moved around on the web and what methods are available for connecting different services. In the real world, we have phone calls and emails to coordinate between different entities, but on the web, we have “protocols.” The most common protocols for moving data from one service to another are arbitrary HTTP requests, formal APIs, and webhooks.
HTTP Requests
The World Wide Web is built almost solely on the concept of HTTP requests. These are the requests that browsers make to push and pull data from the websites they are interacting with. While this data is often interpreted and rendered as HTML, so-called arbitrary HTTP requests can be used for much more.
Whenever data is requested to update a website (such as the current weather, news, or any other type of information), a simple GET request is made to a target address, instructing its underlying server that you are trying to retrieve some information. This information can be used to build internal dashboards and automation tools, or even for more advanced use cases like supplementing information within Torq.
On the flip side, when data needs to be pushed back out (such as when a web form is filled out and submitted), a POST request is made. This is a great solution for automatically filing support tickets or sending emails using third-party platforms without formal API support.
Third-Party APIs
Speaking of API support, one of the most common ways to automatically send and receive data within online services is through the use of formal APIs. An API (or, for the truly unititated, an Application Programming Interface), is a set of contracts that can be used to interface with a third-party application.
In the case of the web, APIs are generally powered by HTTP requests, but with a bit more formality. They offer official support for things like authentication, authorization, and rate limiting, in addition to stability and longer-term commitment to the request contracts. In other words, if you need to integrate with a third-party service to either push or pull data, using an API is far more stable than using arbitrary HTTP calls.
Webhooks
The unintuitively named “webhook” is a web-based endpoint that listens for data from some external source and reacts to it in a pre-defined way. Rather than manually (or repetitively) polling for data using an HTTP request or third-party API call, a webhook can be used to receive that information as soon as it is made available. Think of it like an API, but in reverse.
For example, Slack, Twitter, Stripe, and many other providers can send JSON-formatted payloads to any defined address, allowing you to update internal databases as information changes in real time, or even trigger Torq workflows for more complex operations.
Choosing Your Automation Methods
Connecting an unknown number of services and systems together is no mean feat. It can require a lot of coordination and planning to ensure that the defined automations work as expected, and even then, there is always a chance that the method used to integrate those services won’t stand the test of time.
So, how do you choose an automation method? When is a webhook a better choice over an API call? When should you use an API call over an arbitrary HTTP request? There are a lot of variables to take into account, but it generally comes down to weighing your needs against what’s possible.
Speed vs. Reliability
It’s no secret that an API is far more reliable than an arbitrary HTTP request, but sometimes developing against an API requires more work and overhead than a simple HTTP call. When connecting multiple services into a cohesive automation, determining your risk profile when it comes to speed versus reliability is key. Proofs-of-concept and non-mission-critical integrations are common scenarios where it might make more sense to quickly create an HTTP request instead of an equivalent API call.
Time-Sensitivity
Webhooks are incredibly useful when you need to react to the data as it changes, but this may not always be what you need. Maybe you want to update data on a slower cadence (such as daily or weekly), or maybe you want to batch the events that get triggered by changes in webhook data. A good rule of thumb is that if changing data has time-sensitive consequences like alerts or other automations, then webhooks are the way to go (if available); otherwise, you can feel free to pull the data down only when you need it.
Building Your Automation Workflow
Successful automation is a game of checks and balances and how you connect multiple systems together is often a balance of what is possible and what is practical. Sure, integrating with formal API specifications across all of your platforms might be the “right” way to do things, but it’s important to also consider the time cost of doing that work.
Sometimes, a combination of simple HTTP requests and webhooks can solve for your specific use-case while cutting down on implementation time. Ultimately, what matters is that you take into account how quickly you can spin something up given the available solution paths and how stable it needs to be when making decisions about integration.
To ensure a more consistent and frustration-free experience with automations, platforms like Torq can help establish these connections for you. Torq provides hundreds of pre-built integrations that can perform common security tasks across other tools. This eliminates the need to adapt or expand the interface to the API, and can even help consolidate multiple API calls into a single pre-built action.
Whichever you choose, preparing yourself with the knowledge of various benefits and liabilities for each model will start you on the path to success.
