Pokémon STOP! Winning & Losing in the API Game

The case of Pokémon GO shows why digital enterprises need to get out of API denial

Here we GO again. For quite a while, the Web API community has been talking about “API denial”. Apparently though, the message has not been heard widely enough. API denial happens when a public mobile app is launched and its supporting APIs are assumed to be private and inaccessible. As fate would have it, this summer’s pop culture phenomenon—Pokémon GO—has given us another example to add to a growing list that includes SnapChat, Kayak and UK e-card company Moonpig.

Pokémon GO started as an April Fools' prank by Google spinoff Niantic Labs. Since its launch earlier this summer, the game has spread virally, altered social behavior and even led to car crashes and shootings. In spite of these incidents, Pokémania is viewed as an unmitigated mobile success, the killer app for augmented reality. Of course, much of its power comes from the data and functionality it accesses through the Web, especially its tight integration with Google Maps. In other words, Pokémon GO has a valuable API that is essential to its success. The problem is that Niantic never acknowledged the existence of this API.

As often happens when a new mobile app or Web platform rises in popularity, other people want to get in on the action. When companies encourage the involvement of these third parties through open APIs—such as Facebook, Netflix and even Google themselves do with their Maps API—they help to expand their own app economy. When companies remain in API denial, those third parties find a way in. In Pokémon GO’s case, a number of third-party developers were able to reverse engineer the unacknowledged API and build apps around it, such as Pokevision. Eventually, Niantic realized that their API was being used by these apps and a shadow app economy had emerged that was beyond their control. Citing “terms of service” violations, they shut these apps down.

Pokémon GO players have reacted with anger and frustration, since they had become accustomed to using these third-party apps to augment their augmented reality gaming experience. It didn’t have to be this way. If Niantic had recognized the potential of its API and followed these rules of the API game, they could have fostered those third parties, benefited from their growth and maintained the satisfaction of players:

Rule #1―Acknowledge & Publish Your API Get out of API denial! If you are launching a mobile app for consumers, chances are you are also launching Web-accessible services through an API. Expect developers to want access to that API. Design it for external use. Document it. Be prepared to let them in when it makes sense. Open your mind to their ideas.

Rule #2―Protect Your API Not every third-party developer idea will be a good one. And not every third-party app will be a good actor, whether intentionally or otherwise. Make sure you have a way of granting access only to the third parties you want and a way of controlling usage once access has been given. Define your API’s terms of service and enforce those policies in real time. Also think about the other ways third parties may try to exploit your services.

Rule #3―Help Your Platform Flourish Once you have access to your API in the right hands, engage with those third parties. Observe how they are using the API and how your customers are using those third-party services. Be ready to evolve your API to meet new growth opportunities that benefit your consumers and expand your app economy.

Following these rules to open and manage your API should help you capture new business ideas and reach new customers as easily as trainers catch nearby Pokémon with Poké Balls.

The Author

Matt McLarty

Team Lead

Matt McLarty is an experienced software architect who leads the API Academy at CA Technologies. He helps organizations with their strategy and architecture for APIs, microservices and enterprise integration. Matt recently co-authored the book Microservice Architecture for O’Reilly, with his API Academy colleagues.

Related Articles


How the Facebook API led to the Cambridge Analytica fiasco

How weak API terms of service, lack of transparency, and permissive API scopes led to the Facebook-Cambridge Analytica scandal

Mehdi Medjaoui on Aug 8, 2018


Applying and Extending DHARMA

This post gives some practical examples of the DHARMA method for API Security in a Microservice Architecture, and also shares some opportunities for extending the model.

Matt McLarty on Jul 9, 2018

Microservices and APIs
API Strategy

Microservices, APIs and Innovation: The Power of APIs

Explore the role APIs play in empowering teams and enabling organizations to innovate.

Mike Amundsen on May 24, 2018

Join the Conversation