Sports media giant ESPN last week announced that it will be retiring its public API in December. Effective immediately, the company has stopped issuing new API keys to developers.
Launched in March 2012, ESPN's API gave developers programmatic access to the company's content, including headlines and research notes. At the time, ESPN remarked that its API efforts were "fundamental to its business strategy going forward." But as company's strategy has evolved, ESPN came to see its public API in a different light.
According to ESPN's Chris Jason, "We have made the difficult decision to discontinue our public APIs, which will enable us to better align engineering resources with the growing demand to develop core ESPN products on our API platform."
These comments are similar in nature to those made by Netflix, which recently announced that it too would be shuttering its public API. In Netflix's case, the company ultimately determined it could not support its internal development needs with its public API. Lacking a compelling business case for a public API, Netflix decided to end its public API program instead of maintaining two separate APIs.
A good idea to begin with?
While APIs are growing in popularity, and more and more companies are launching their own public APIs, it is increasingly clear that public APIs aren't a good fit for every company. In some cases, companies can only determine that a public API isn't a viable proposition by launching one and seeing how the market reacts and its needs evolve. In other cases, however, the desirability and viability of a public API is questionable from the outset.
For instance, I was initially skeptical when ESPN announced its public API, noting that the terms around its use were so incredibly restrictive as to call into question its utility. I also pointed out that the company seemed to be "promoting its API to the entity it's least useful to -- the average developer."
The good news is that the Netflix and ESPN experiences provide helpful case studies for companies contemplating the launch of their own public APIs. As businesses become more familiar with the rewards and challenges of launching and operating public APIs, and using them to support internal development needs, we'll hopefully see fewer and fewer instances of companies launching public APIs only to later shutter them.