Learn more about the risk areas related to APIs and web services during due diligence in M&A transactions involving software, and how to reduce each risk.
Today, developers are more likely to assemble code for their applications than to write it. Sure, they still write the critical business logic. But with codebases comprising up to 90% open source or third-party components, developers save time reusing code for commonplace functionality. One type of component available for reuse is API-based web services, many of which are free to use for basic functionality. But using API-based web services can create issues regarding copyright, end user licensing, terms of use, and data and privacy policies.
Developers frequently find useful APIs for their applications on the internet. But development organizations might have no control, or even knowledge, of which APIs their developers are using. This could go on for an indefinite time. Then one day your company decides to buy the organization. How can you reduce the risks related to API-based web services involved with the acquisition?
When you’re considering acquiring a company with a substantial valuation based on software, there are four primary areas of concern when that software makes calls to API-based web services:
API-based web services come with copyrights and conditions of use that you need to understand. Terms of use can also be complex and dynamic. When terms of use change, users agree to the new terms simply by continuing to use the API-based web service. Suffice to say, when you buy a company licensing API-based web services, you also buy their legal and compliance risk.
API-based web services pose two risks to acquirers: the data that APIs send and the data they receive. Sent data can leak or be eavesdropped on. Received data can include executables, tampered images, viruses, or malicious code. And data going in either direction can be subject to man-in-the-middle attacks.
Organizations sometimes treat data from APIs differently than data they get from other sources. All data, especially personally identifiable information (PII), needs the same tender, loving care when it comes to data privacy. As the acquirer, you must do due diligence on how the target’s application handles API data, how it combines that data with anonymized data from other sources, and where (geographically speaking) that data is sent to, received from, stored, and processed to comply with regional data privacy regulations such as GDPR in Europe.
API-based web services, in their free state, offer no SLAs. When looking at a potential acquisition, you need to know what continuing risk the use of free web services entails. You could end up facing a business continuity issue if the API license is revoked, the API is deprecated, or a competitor buys the API provider and restricts access to direct competition. You must put in place contingency plans for when—not if—an API becomes unavailable for any reason.
As with open source software, the way for acquirers to reduce the risk of API-based web services revolves around full disclosure and discovery. Basically, it’s a 3-step process:
This blog post provides a very high-level summary of how acquirers can reduce the risks posed by API-based web services in the merger and acquisition process. For a more detailed discussion of the due diligence required, check out our new white paper Best Practices for Reducing Web Services and API Risks in M&A.
Derek Handova is an enthusiastic white paper writer and content marketer in the B2B and technology spaces. Previously, he has led content creation efforts at prominent companies such as Altera, BearingPoint, Inc., Check Point Software, Harris Corporation, Solectron Corporation, and other Silicon Valley icons.