API Monitoring – You Are Probably Doing It Wrong

The monitoring of APIs is important, whether the APIs are for affiliates or just internal. They are the backbone of your business. Despite this the majority of companies are not monitoring their APIs, and those that are aren’t doing it well. So 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. Those have selenium and appium tests constantly interacting with the website to confirm it is working functionally. 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 statuscode 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, Runscope, and Postman 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. In it 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.

That is what API Fortress is built for. Try it for free.