The Importance of Bi-Directional Incident Response Integrations

In the age of Everything as a Service and APIs, it’s easy to imagine turning different parts of incident response and communication into automated workflows. But to build these workflows, we need a way to easily integrate with dozens and dozens of various APIs. Integrations allow us to connect two or more systems — often exchanging data— and power processes.

One of the most popular forms of integration is using webhooks. Webhooks are a user-defined callback using an HTTP POST. It allows information to flow one direction from one system to another, often triggered by some action or update. When there is something to alert you of, it will send the data to a specified URL.

I’ve been a massive fan of the concept of webhooks for years because it allows integrations to be built between systems that don’t necessarily have strong ties with each other. Webhooks make it easier to get real-time data (or as close to real-time data as we can get) out of systems in an automated way.

But webhooks alone are not enough.

There are two main types of integrations: APIs and webhooks. Both have their pros and cons, but for a genuinely bi-directional integration, you need a combination of the two. Webhooks are super useful for alerting, but APIs complete the bi-directional integration circle by enabling data to sync between systems.

What is a bi-directional integration?

A bi-directional integration allows data to be synced between two or more systems, such as your monitoring and ticketing system. During an incident, bi-directional integrations mean you can pull data and take action from one place rather than running through all your various tools, preventing distractions at critical moments. They can also pull more data and context into the investigation process and later into the incident timeline, giving a more complete picture in an incident review.

Webhooks + APIs = Bi-directional integrations

Bi-directional integrations take advantage of both webhooks and APIs’ strengths, so there is both a give and take of data in incident response. Bi-directional integrations can ensure that data is not siloed in one system but rather shared across multiple systems.

Webhooks

As previously mentioned, webhooks are great when you need real-time data updates, which is pretty much in any incident. Webhooks do not get sent unless there is updated data to share. Webhooks can efficiently trigger a workflow application compared to polling an API to inefficiently check for updates. Polling can be problematic for other reasons, too, such as rate limiting and the amount of work, infrastructure, and time it takes to implement good polling. Making API calls to only get the same response can cause rate limiting issues and prevent future API requests. With webhooks, you don’t need a middleware like with many API requests.

A significant issue with webhooks is that it is hard to manipulate data in the third-party system that the webhook is coming from. This is where an API-based integration becomes handy.

APIs

Often during an incident, we might get an alert, which can be powered by a webhook. But we often need more data about what is happening at that moment or need to take action. This is where APIs are useful!

API integrations usually include an application that is making the API requests and a remote system with a server receiving and responding to the requests. With API integrations, it is a two-way conversation between systems compared to a webhook, which is one-directional.

Often in an incident, you either 1) need more data or 2) need to take action. APIs allow us to get data that gives us a better idea of past or current state and will enable us to take action based on what we are seeing. This can even come in the form of communication, like ticketing systems, status updates, or other forms of communication like email. While a webhook is one-directional and a one-to-one relationship with two systems, APIs make it easier to modify data across multiple systems at once, a one-to-many relationship. Another example of when APIs are more useful is when there is a lot of data incoming from a system—API pagination can help parse larger data payloads.

Transposit to the rescue

The tricky part of having API integrations complete the bi-directional integrations cycle is that reliable API integrations from scratch take a deep understanding of possible failure cases, the structure of different APIs data schemas, and the relationship between data from other systems. Add in things like rate limiting, pagination, authentication, testing, and monitoring, and you have a good-sized project on your hands. It can be expensive to build and includes large investments in processes, applications, and data management.

Transposit’s powerful integration platform has a complete map of what different APIs look like. This makes it easier to integrate with all of an API, not just a few endpoints that have to be manually strung together. It also supports the common pain points, like rate limiting, pagination, authentication, testing, and monitoring, that someone building an API integration for incident response may face. Transposit supports incoming webhooks that can alert on-call teams of a possible incident or important updates while also taking action to investigate and remediate an incident within multiple systems in your stack.

By using bi-directional integrations with Transposit, you can finally say goodbye to distributed, manual workflows that slow down incident response and put a burden on your engineering resources.