Critical Questions to Ask When Choosing a Third-Party API

Application program interfaces, or APIs, help us integrate toolchains including version control systems, continuous integration servers, and workflow automation. APIs are extremely useful, but they’re also often challenging to work with. The more you know about APIs, the more effective your configuration management practices will be.

This article exposes the risks and hidden costs involved in the seemingly innocent decision of which third-party APIs to use to gather and report data, offload critical functionality, and save implementation time. I’ll address some typical reasons the decision-making process over third-party use is overlooked, as well as how to make good choices confidently and consistently.

The Artistry in Making Business Decisions

There is an art to making good decisions over which third-party APIs you consume in your web or mobile apps. Your decisions are a critical aspect of shipping compelling content that people want. Apps that bring insights together by framing information, such as the Apple Watch and Tableau, can be so enthralling that people seek out how to be among the first to use the technology.

Apps that lack context between data points miserably fail consumers in a critical way: Human brains are hardwired to see differences. In order to compensate for this natural skew, we build visuals or narratives around our data in order to show themes and outliers. As such, it’s often a forgone conclusion to outsource the source of your data, looking to third-party API providers to help you focus on the unique value you bring to your consumers through context.

Is Saving Time Worth the Cost?

In general, digital businesses make very informed decision about whether to trade off employee time with the cost of having someone else do “busywork.” Their employees’ time is worth far more directing the motions of the business than doing a highly specialized implementation task, unless those tasks are a key activity of the business. Be it agency-based or cross-functional team structures, companies that drive invention often do so by trading some implementation details for a focus on primary business goals.

There’s a pernicious, rotten seed in that line of reasoning: Offloading implementation also offloads ownership over authority. No longer do you know the details, dependencies, or flaws in the implementation. But as it turns out, devils are often in those details, waiting to cripple your business plans.

For instance, take the widespread outages of GitHub, Twitter, Facebook, Salesforce, GoDaddy, Amazon AWS, Bank of America, and even more sites in 2012. Their downtime was bad for them, but the worst news was for companies who integrate with these services. Whole sales floors, e-commerce sites, and financial systems like payroll were literally shut down until problems could be diagnosed and resolved.

In another example, Apple iCloud and the App Store both had outages lasting an entire business day each, leaving the brand-heavy behemoth in a relatively new position of apologizing to consumers. This event left the premise of authority ownership at Apple exposed. What IT/Ops team takes twelve hours to resolve an internal DNS problem?

This lack of control, especially in decisions around third-party software, results in businesses that look healthy on balance sheets but suffer internally from “dependency disease,” rotting the decision-making process from the inside out. In the design and development phases you can use techniques such as API virtualization to minimize friction, but once you get to production, issues with third parties rise right back up.

Cost, Time, and Risk Are Four-Letter Words

The problem with third-party web APIs isn’t that they cost money. In fact, subscription cost and benefit is the best way to impartially measure value in API economy terms. If people agree with your price, it means they’ve found you to provide a worthwhile service better than any of your competitors. The numbers speak for themselves; the subscription cost of a third-party API is easily parsed and measured.

Unfortunately, risk is not always quantifiable. How do you report how much risk a project takes on when a new third-party web API is implemented into the code—a kind of “dependency” risk? Do you track increases or decreases to your dependencies over time? How is the final consumer experience affected by a poorly performing third-party API?

It’s not easy, but these concerns can be addressed by rolling up your sleeves and breaking the problem down into answerable questions. Below are some questions to expose how ready for success a third-party API vendor is:

• How often does the third-party site go down?
• What is their SLA, and how do they prove they met it over the past year?
• How often do they test execute their disaster recovery plan?
• What are their financial strengths as a company? Is this their only product?
• The existing way works, but it is flawed. How much am I losing due to not switching to a different solution?
• What have their IT/financial audits exposed, and how have they resolved these issues?
• What compliance standards (that matter to you) do they support?
• Do they escrow their code with a third party in case of bankruptcy?
• What other customers from your industry do they have ready to talk to you?
• What’s their business continuity plan like if critical aspects of their business experience disaster?
• As a software company, what’s their software delivery lifecycle process like?
• What type of customer success and support team relationships do they keep with customers?
• What are their community engagement and user adoption like?

This list is only to get your brain churning on what questions are most important to your business. There may be unknown bias or misconceptions about APIs in your organization precluding you from getting to the point of asking these questions. However, asking some of them will help expose risk before you’re held victim to it.

Data-Driven Decisions Aren’t a Silver Bullet

There is some bad news to all this: Information alone does not guarantee you’ll make good decisions.

Data itself can be wrong. It can be misinterpreted. You can focus on the wrong data points. Data also changes, especially API performance over time. However, rigorous questioning prompts people to talk about expectations and goals up front, before a decision is made.

The good news is that you can still maintain authority and ownership to a degree when using third-party web APIs, based on how far you want to take your analysis. For a developer who might not be directly involved in disaster recovery procedures or revenue loss scenarios, any API will do just fine. But as many senior management and operations folks know, understanding your data—data used by your code and data used by your business to make product decisions—is vital to making decisions confidently.

Truthfully, it’s not the data you’re after. It’s developing a process by which you exercise your authority and ownership over the final product. It could be your website, your mobile app, or partner integrations to your product. Finding confidence in the final result starts with being okay with getting into the dirty details of a third-party API vendor, asking the right questions, and having the right people help you answer them.

As well as interfacing with the application itself, APIs also help you manage your entire software development process. Understanding how they work can help you and your team achieve success.