×

Just because you don’t own it, doesn’t mean it won’t impact your users. If you manage an application programming interface (API) that other internal or external users depend on for data and processes, when that API fails it won’t only impact you.

APIs are wonderful because they connect services and let us pass data back and forth between uniquely managed systems, but that connectivity and interdependence creates vulnerabilities. When it comes to the performance and availability, it’s important to monitor the APIs that we depend on and the APIs that we provide for others.

When starting to monitor APIs, consider both:

  • APIs that your web site or native application relies on for critical data or processes, and
  • APIs that you manage that customers, end users, or developers rely on for data or processes

When monitoring both of these types of APIs, it’s important to test:

  • Availability – Is this API endpoint up? Is it returning an error?
  • Response Time – How quickly is the API returning responses? Is the response time degrading over time? Is the response time worse in production than in pre-production?
  • Data Validation – Is the API returning the correct data in the right format?
  • Multi-step Processes – Can I successfully save and re-use a variable from this API? Does authentication work as expected? Can I complete a transaction with data from this API?

Some Examples and Use Cases

When an API fails and disrupts the performance or user experience on your site this failure reflects on your company. End users and customers likely won’t recognize that a third-party could be at fault. And depending on how critical that API is to a transaction process, this failure could impact your bottom line right away.

For example, if a key component of the checkout process on your website is a location-based search and you rely on a third-party API to provide the search by location, when that API doesn’t work correctly then your potential customers cannot checkout successfully.

An example of a search that relies on location data
An example of a search that relies on location data

Or, imagine that you developed an application that requires authentication from a social media platform. If the API for that social media platform goes down, your users might not be able to log into your system.

When Twitter's API goes down this impacts hundreds of dependent sites and services
When Twitter’s API goes down this impacts hundreds of dependent sites and services

As a developer or a site owner you may decide that the benefit of relying on the third-party service outweighs the risk of these types of failures. In order to accurately assess the risk and have visibility into the impact of these services over time, it’s crucial that you monitor the part of your site’s user flow that relies on an API.

One way to monitor this type of user flow or transaction would be with a multi-step user flow in a browser. If your transaction doesn’t run in a traditional web browser or if you want more fidelity in reporting and alerting for the API specifically, then a unique test that monitors only the API or API transaction will be your best bet.

If you have an open API that you’ve made available to partners or developers, then you have a responsibility to ensure that the API is available and working as expected.

Consider a case where your company has a service license agreement (SLA) with a partner to ensure that an API is not only available but sending data in the correct format 99.95% of the time. As the owner of that API it’s crucial that you have active monitoring with alerting on your API so that you can respond to any degradation immediately before it impacts your partner.

Or, let’s say that you’ve developed a new internal API that passes order data from a mobile device to a system in your product warehouse. Maybe it’s critical that the data passes to the warehouse within 2 minutes time, or the entire production schedule will be off. When you developed the API and tested it in staging it always passed data successfully within one minute, but when you launch the API and start processing real requests you notice that the real response time is creeping up closer and closer to that 2 minute threshold. Without active monitoring on the API in production your team might assume that the developed API is fast enough based on pre-production tests.

If you host an API that other people rely on, be sure to actively monitor that API in both pre-production and production environments.

Conclusion

Whether it’s to keep tabs on your own APIs or see the impact of external services that you rely on, it’s important to monitor APIs for availability, functionality, speed, and performance. If you know you have an API that’s been unreliable in the past and you’re not actively monitoring that API, start the conversation with your team and develop a plan to begin monitoring that API today.

Suggested Blog Posts