The True Cost of Using Public APIs

How ubiquitous are APIs in today’s development processes? Try asking an engineer how many APIs their project integrates. Most teams won’t know the answer. From analytics tools to maps and cloud hosting, modern applications use a hefty collection of internal and public APIs. Developers use these to quickly assemble applications that would otherwise take much more effort to build. However, there’s a forgotten expense not typically calculated early in a project.

When you add another API into your software, its impact is felt long after that initial integration. Developers also need to maintain the connections, which includes identifying issues as they arise. Too often, the problems don’t surface until a user reports a bug. For most companies, that’s way too late, but building tools to expose the problems is only an option for the most show stopping features.

In this post, we’ll look at the user experience of API errors—and just how common they are. And we’ll see what’s needed to reduce these API headaches.

How Customers Experience Broken Integrations

Modern applications rely on an army of APIs to bring quality features to their users. Whether the product is a web, desktop or mobile app, frontend or backend, the developer is going to rely heavily on the functionality of third party APIs. When these fail, customers cannot tell the difference between which errors to attribute to the developer and which to the third party. All they see is a broken application. One broken API can cause a bad customer experience, which can in turn lead to a direct loss in revenue.

For example, imagine you are creating a new bike sharing app. You’ll need to write plenty of original code, but you can also build on existing tools. In fact, most developers wouldn’t even try to recreate the most common infrastructure available via API.

Your app will likely need to integrate with:

• Cloud hosting
• Maps to show locations of bikes
• Geocoding API to convert locations
• Payments service
• Communications services

If you’re going to share bikes, you obviously need to know where they are and share the data with your users. So, you might plot the bike locations on Google Maps. Depending on your monetization model, you might even need to track the distance between their pickup location and destination to charge them by the mile. If this is the case, your app also requires a payment system. Integrate Stripe for credit cards or take bank payments via Plaid, a financial services API which was recently acquired by Mastercard.

Even simple applications require functionality that adds up. You might need to send SMS or email. Or integrate a secure chat feature like you’d find on Lyft or Craigslist. Meanwhile, you can employ a service like SendGrid or MailChimp to automate email reminders and keep your customer base engaged.

Suddenly, you are sitting on a massively complex system which not only makes errors more difficult to track and mitigate, but also means your functionality relies on countless third parties to minimize and track their own errors. Users see one broken element of an app as indicative of a broken system.

Developers frequently monitor and address the performance of their own systems. This includes writing unit tests, paying down technical debt, and frequently reassessing functionality. Additionally, they might bring in quality assurance teams to look for user experience issues.

However, many teams fail to take these same measures to analyze their APIs. Without those measures, it’s easy for them to miss the ways APIs are impacting user experience. You should use the same rigor with integrations as you do with code you control. This way you can be immediately notified when response times spike or errors occur.

API Errors Happen More Than You Realize

As much as applications rely on public APIs, public APIs are notoriously unreliable. Each API has a number of ways to fail and most apps incorporate multiple APIs. You need to expect errors and ideally try to mitigate them. You cannot wait for users to report problems on their own. And waiting for errors to resolve themselves won’t work if your user has moved on. When customers encounter these sorts of roadblocks, they are not likely to investigate where the problem started.
SmartBear’s 2019 State of APIs report found that, “organizations that view API monitoring as a top priority are vastly outperforming those that do not at resolving performance problems.” The report attributes this to sky high customer expectations. Their survey found 57% of API consumers expect issues to be resolved in one day, and 40% expect a fix in 12 hours.

APIs can fail to return requests for a number of different reasons:

• Response Time: In these days of high expectations, a slow app can be as bad as a broken app. Response time is also the canary in the coal mine that larger issues may be coming.
• Mismatched Error Code: Proper status codes help adjust to API errors, but you can’t always count on the provider to send it. In some cases, you get a 200 -- meaning no error has occurred -- but the response still has error details. In these cases, a person surveying the data would be able to tell there is an issue, but the software doesn’t know to bring it up to anyone.
• Authorization Credentials: APIs run authorization credentials on who is making a request in order to determine if the right person is getting information. This helps keep the system and your data secure, but also adds yet another layer where a valid request can be tripped up. Credentials can time out or be revoked, but a user only sees an error message and no explanation.
• Rate Limits: Many APIs control the flow of traffic by implementing rate limits on requests. These might be on a daily basis or by the second. Building in logic to handle rate limits (i.e., 429 errors) is time consuming. It also creates much better experiences and decreases data loss when you can automatically retry.

While many developers incorporate some form of API monitoring, they aren’t always focused on external APIs. Too often, it requires teams to be proactive rather than reactive. That means you need to know exactly what errors to look for before they happen. You need to know about the errors you didn’t anticipate, too. Teams must be armed with these sorts of insights in order to meet user expectations.

What’s Needed to Eliminate API Headaches

Modern applications require numerous connections to other APIs to function. Like any complex machine, when one gear is out of place, the system breaks down. To identify and fix errors requires significant tooling around every API call you make. You need to go beyond monitoring, with retry logic and anomaly detection.

Being proactive about API maintenance means having an extreme awareness of your API network. Each time a user sends a request, you need to know how long it took and what data is returned. These insights help to predict when future errors may occur. Meanwhile, if the request returns an error, you must be able to look at the details of the request and respond swiftly. This way, the scope of API errors is limited to just a few users. Unfortunately, developers rarely have access to such intricate tooling. It is difficult to build in-house and consumes significant time and resources.

Hoss is focused on this problem. Hoss tracks and manages the APIs companies consume to help developers limit these hassles and avoid the damaging effects of poor API performance. The service provides a full, easy-to-understand dashboard of API analytics so developers can make better API-driven products and seamless user experiences. API proliferation has enormous benefits, but it also comes with costs – the developers who take action to mitigate those costs are best positioned to take advantage of the API boom.