Companies that rely upon third-party public APIs (for example, those from Facebook, Twitter, and other API providers) to do business have always been at risk. This is nothing new. Over the last decade, ProgrammableWeb has watched and reported as many of the APIs that developers rely on (i.e., Netflix, ESPN, Edmunds, Facebook, LinkedIn, Twitter, etc.) have either significantly dialed down their functionality, changed their API terms of service, or shut down altogether. But none of these made mainstream media headlines the way the recent Cambridge Analytica fiasco involving Facebook’s APIs did.
The damage was widespread. Not only has the much-maligned UK-based firm shut down, but many developers are also feeling the pain as Facebook and other API providers adjust their API capabilities accordingly, in many cases without warning.
For example, in the initial wake of the entire affair, Facebook took swift action by significantly paring back its API. But the company wasn’t done. In early July 2018, it further restricted some APIs by requiring an app review first. The news wasn’t all bad as some APIs that were initially shuttered were restored (under the new app review requirement). The company also left the door open for more changes when, in its statement to developers it said, “We will keep you updated on the additional changes we make.”
That initial swift response by Facebook and others really caught our attention here at ProgrammableWeb. Against the backdrop of looming deadlines for compliance with Europe’s General Data Protection Regulation (GDPR), a slew of API providers broadly thinned out many of the resources they originally made available through their public APIs (if they didn’t shut their APIs down altogether, that is). ProgrammableWeb recently reported that Favstar, a company that helped identify great tweets and Twitter users to follow had to shut down due to sudden changes to Twitter’s API. Developers, many of whom had no idea the cuts were coming, were left in the lurch as their apps suddenly broke. Although we’re not seeing the death of the API economy, we at ProgrammableWeb are declaring it “the end of the API economy as we know it.” Or, to put it more aptly, “The end of the API economy as we often fantasize it to be.”
To put it bluntly, we’re not sure how many times this ugly history has to repeat itself before both developers and API providers get the hint: There’s a huge amount of risk that goes with providing and consuming public APIs. For API providers, that risk could span from legal vulnerabilities to financial losses to risking a brand’s squeaky clean reputation. For developers, the dirty truth is that the rug can be pulled out from under you at any time. Since the birth of the API economy in 2005, building a business or product whose profitability wholly or partially relies on the ongoing availability of third-party APIs that you have no control over was and is a bad idea.
But, refactoring your existing IT infrastructure into more of an API-led composable enterprise and working with internal developers and specific external partners to drive significant value is an API Economy idea that still holds true promise.
Cambridge Analytica and Facebook: The Current Event
We all know the story by now. Aleksandr Kogan, an employee of consulting company, Cambridge Analytica, creates a Facebook app and names it, “This is Your Digital Life.” The app encourages users to take quizzes about a variety of topics. In order to take one of the quizzes, users grant permission to Cambridge Analytica to access Facebook profile information. With a click of the button the user allows Cambridge Analytica to view personal information that includes friends and likes of third-party pages. Cambridge Analytica uses this data to fuel strategies and tactics for political purposes. All the data gathering is done via the Facebook API.
Pandemonium breaks out. The story becomes front page news, Facebook CEO Zuckerberg gets called to field apparently rhetorical questions from Congress, and Cambridge Analytica declares bankruptcy. But the story doesn’t end there. In April of 2018, Facebook changes its API in a big way. For example, the company removes the publish_actions option on the Login API, effectively shutting down a user’s ability to share content on Facebook and Instagram. Also, Facebook stops publishing the Application Analytics App Events Export API. Those are just two of many other Facebook changes.
Facebook is not the only brand reacting. Instagram (also a part of Facebook) shut down a bunch of its API endpoints. Gone is the ability to get user information by user-id as is the capability to do a general search on users. Even the ability for a person to get information on himself or herself is gone, and so is access to media information.
Companies are turning off the data spigot, satisfying the PR gods throughout the API universe. But what about all those honest, compliant companies that consumed the data coming out of those endpoints? What’s to become of them? The sad fact is, barring the few whose apps get approved to use the trimmer, slimmer APIs, they’re pretty hosed. At best, they’re going to have to start rewriting a good segment of their codebases. At worst, they’re out of business. Some might even be on the receiving end of some sort of revenue-seeking litigation.
A Case in Point: PeopleLinx and LinkedIn
Shutting down an API can spell a company’s doom. Take PeopleLinx. PeopleLinx, a company started by two former LinkedIn employees, provided a dashboard application that enabled companies to optimize their presence in the B2B social media space. The way the PeopleLinx platform worked was that it wired into a social network API such as LinkedIn’s in order to inspect opportunities for improvement in the way employees configured their user profile. For example, intelligence in the PeopleLinx platform had the ability to get a user’s LinkedIn profile photo via the API and then inspect the image to determine if the headshot showed two eyes. A profile photo showing two eyes indicates a professional looking headshot. If the photo did not meet the two eye requirement rule, the employee and company were notified so they could make adjustments.
PeopleLinx customers loved the product and as a result, the company made a lot of money. Needless to say, a good deal of PeopleLinx’s business depended on having access to the LinkedIn API, which it did until March 2014 when LinkedIn sent the company the letter shown below, informing PeopleLinx that it was disabling access to the LinkedIn API.
As a result, we will disable your access to the LinkedIn APIs in 30 days….
LinkedIn prioritizes the companies that it partners with based on strategic alignment, size of opportunity and current needs. At this time, we do not believe you are adding sufficient value beyond our existing products to justify a partnership.
Just like that the LinkedIn API was going away. PeopleLinx felt the impact immediately. Developers fled, morale plummeted, and customers got antsy. Some of them even took the time to to write to LinkedIn asking it to reconsider its position. But the social media monolith would not relent, and it terminated PeopleLinx’s access to its APIs. Fortunately the company was able to regroup, but it took a lot of painful time.
PeopleLinx is not the only victim of being shut out of a mission-critical API. There’s also the story of Datasift.
Killing the Competition: DataSift and Twitter
DataSift is a multimillion dollar data curator. The company applies its analytics to the large amounts of data emanating out of data fire hoses. The results are new insights of significant value to its customers. One of DataSift’s firehose providers was Twitter, from which it got hundreds of millions of tweets a day. DataSift and Twitter had been doing business together since 2011.
Then in May of 2014 Twitter acquired Gnip. Gnip delivers a service similar to the one DataSift provides. For all intents and purposes the companies are direct competitors.
After the acquisition, Twitter decides to bring DataSift-style data curation in house using Gnip’s technology. Twitter informs DataSift that access to the Twitter fire hose will expire in August of 2015. DataSift CEO, Nick Halstead tried to reach an agreement with Twitter to continue access to the API, but the company declined to reconsider. Hence, one company depending on another’s API sees the termination of its data spigot. Fortunately, as with PeopleLinx, DataSift recovers — this time by forging an exclusive relationship with Facebook that’s in force today. DataSift was lucky, but others might not be.
A Path of Broken Promises
These are just a few examples of the carnage, and there are plenty more. The original promise of the API economy is that standardizing both access methods and data formats provides the foundation by which outside companies can use the APIs to create new, compelling services and user experiences. One of the chief selling propositions — actually more of a theoretical proposition since it rarely happens — is that unknown but innovative developers will flock to public APIs and drive untold value and fortunes. True or not, implicit in these propositions is an understanding that three basic conditions need to be in place. The first is that the structure of a given API — what’s known as the contract — needs to remain consistent. For example, there can’t be one set of resources available through an API on one day, and a different set of resources available the next. Second, access to an API needs to be predictable and not subject to arbitrary business decisions or the whims of the API provider. Third, APIs need to perform in a reliable manner.
Sadly, these conditions have deteriorated over time. The cause of the deterioration might be due to the natural entropy incurred by the sheer volume of APIs in play, combined with the number of companies and people using them. Alternatively, the decline might be the result of increasingly aggressive competition between companies for the vast amounts of money to be made.
One of the biggest reasons has to do with the failure of any true value to materialize from the effort of launching and operating a public API, which happened with Netflix, ESPN, and more recently, Edmunds. Or maybe the failure was triggered by a privacy debacle like Cambridge Analytica. Still, regardless of these reasons, that deterioration is happening. More API providers are abandoning their original public API strategies. From the developers’ point of view, promises are being broken. This translates into a growing distrust of API publishers by API consumers. Some companies have gone as far as to accept the growing deterioration of the API ecosystem and make dramatic efforts to adjust accordingly. To quote Jake Stein at StitchData, a Philadelphia-based data aggregator:
“We have a team of people that are staffed full time adapting or accommodating problems in existing APIs. Not only are the APIs changing, but there are also performance issues. We’ll send a request for some batch of data and then for some mysterious reason it won’t work, even though it worked yesterday.”
So what’s the takeaway? It’s pretty simple. The promise of the API economy propelled the technology into the forefront of today’s digital marketplace. But, some of its promises have been short lived. Between the rate of unannounced changes, unreliable performance, unpredictable business policies, and knee jerk political reactions, you can make a good argument that the API economy as we once knew it has ended.
Finally, should you be considering creating or investing in a company that depends on using or providing an API to do business, you’ll do well to think long and hard about what you’re doing. Given the current state of affairs, an API provider can bring your business to a grinding halt because of an arbitrary whim. Now if you build it (an API), there’s a diminishing likelihood that they, the developers, will come. In many ways it’s a crap shoot, and as with any game of chance, more often than not, losers outnumber winners.
ProgrammableWeb’s Editor in Chief, David Berlind, co-authored this article.