API Monitoring — You May Be Doing It Wrong

At API Fortress, we view the monitoring of APIs as important, whether they are for affiliates or just internal. APIs are the backbone of your business. Despite that, the majority of companies are not monitoring their APIs, and those that are aren’t doing it well. Let’s explain what people are doing and how that isn’t enough.

There is a misconception that an API is either "up" or "down." People seem to assume that if the API works once, it will always work. Oddly, they don’t have this belief about websites and applications. The average company knows that websites can be up but have functional issues. This is why billions of dollars are spent creating automated functional tests for websites and apps. Much like a website, an API is alive and constantly evolving. The vast majority of API problems are more nuanced than being "down." A down API is easy to catch, but an API that responds improperly is where companies lose the most time and money.

Let’s take a look at the Uber API. When you make this call, you’ll (hopefully) receive a status code of 200 and a payload. Great — that means the API received and responded. Oddly, this is where people conclude their monitoring setup. Many of our customers switched to us from platforms like Alertsite and Runscope because that is about as far as they could go without having to write JavaScript code. What is important to remember is that often, the person tasked with creating and maintaining the API monitor isn’t a developer. Therefore, a solution needs to reach the right balance between ease of use and power.

A proper API monitor shouldn’t test uptime, it should test functional uptime. Here is what I mean by that.

If we dive further into the Uber payload, we see that there is a list of products, and each one has specific data associated with each object. For example, image is a URL, which the app uses to show the car type visually. Also, display_name should be one of Uber’s products (UberX, UberPool, etc…). What happens when the image comes back but isn’t a URL? Or Uber adds a new product type without informing the app team? Then you have a broken app, and a lost customer. This sounds unlikely, but this exact scenario happened a couple years ago and Uber didn’t catch it right away. Etsy has problems like this nearly daily.

Smartbear has incredible stats on this phenomena from a 2016 report. They found that only 10% of API issues are resolved within 24hrs. Nearly 25% of API issues remain unresolved for over a week. These numbers are shocking, and yet easily fixable. Testing on a build/deploy is great, but that same level of testing should be done constantly as a monitor. One test interacting with multiple microservices, and validating every object and the data associated. That is the only true test of uptime, and yet it is nearly never done.

Don’t let your customers find functional outages for you. It’s your API and your responsibility. Show your APIs the same care your website receives.