DEV Community

Cover image for The top 4 reasons to start monitoring third-party APIs
Mark Michon for Bearer

Posted on • Originally published at bearer.sh

The top 4 reasons to start monitoring third-party APIs

How resilient is your application? Maybe you've set up a suite of logging tools, an APM, and tests to handle all your own code. What happens when a third-party API goes down? What happens when it stays up but slows down to the point that your dependent services start to fail?

Finding a modern application that doesn't rely on third-party APIs is rare, particularly with the abundance of social login and sharing. So what can you do to ensure that your application isn't beholden to the performance of a third-party API? Monitor them and set up contingency plans.

Let's look at a few reasons you should be keeping tabs on the APIs you use.

1. Avoid bottlenecks

Avoid bottlenecks

Developers, hopefully, spend a good amount of time making sure their applications are fast and responsive for users. What they can't ensure is that an external request is as fast. Monitoring API requests for latency trends can help identify inconsistent or low performing requests that might create bottlenecks in your application's logic.

For example, if your application pulls in data from a user's Twitter profile in order to populate their user account in your application, you'll want to know if the delay is in the way you transform the data or the way the data gets to your app.

2. Make sure you need them

Usage

As your application adds features, pivots, deprecates legacy features, and continues moving forward it can be easy to forget about connections to APIs that receive less attention or use. Monitoring usage allows you to keep track of the most important APIs to your business, and even discover APIs that your team forgot about. This data allows you to allocate resources toward those valuable APIs for your business, and identify under-used or "dead" APIs that can be removed or replaced.

3. Identify fallback priority

Identify fallback

When relying on external resources, like third-party APIs, fallbacks are vital to ensure your application doesn't fail when they do. This is often done with resiliency patterns, like the circuit breaker. Your low priority APIs may only need a circuit breaker and retry logic, while more critical APIs might require more advanced caching and alternative APIs to provide their functionality.

The metrics gathered through monitoring, like those gathered by the Bearer Agent, can help inform these decisions and prioritize which fallbacks are best suited for each API.

4. You can't control someone else's service

Downtimes

While obvious, it's easy to forget that you can't control the performance and uptime of an API you rely on. Planned downtimes often come with a warning, but not all problems are caused by an API being completely down. Outages are unavoidable and while many popular APIs become more reliable over time, they still go down or have diminished performance.

At the time of this article, we've seen recent outages in Box, partial degradations in Stripe's API, increased errors with Facebook's GraphQL API, and countless others.

While these may be brief, if the problem causes your application to fail and your user experience to suffer, then the downtime brevity is unimportant.

Start monitoring today

Don't be caught off guard when there are problems with an API you rely on. You can manually set up repeating tests on the endpoints you use often, and some will even offer a /health endpoint for this specific purpose.

At Bearer we've built a better solution. Our Agent monitors all outgoing API calls automatically and reports the requests and responses to an application-wide dashboard. Here you can see metrics on API performance, usage, and error rates. With the ability to set custom rules your application can adapt to unreliability in third-party APIs dynamically.

Start monitoring third-party APIs today with the Bearer Agent.

📢 Why monitoring third-party APIs was originally published on the Bearer blog.

Learn more about Bearer.sh (hero image)

Top comments (0)