How to Manage the Risk of Losing API Access

Businesses that consume APIs, whether to build products or manage internal workflows, need to treat APIs the same way they would any other supply good in their value chain. Risk managers and business strategists need to determine the size of the risk associated with consumption of an API. For example, several banks are beginning to consume the Google Maps API to show locations of their ATMs and branches. If there was a problem with accessing that API, you could argue that it could be a low risk that didn’t affect the business so much. But if Yelp were to have difficulties accessing the API, that would be a high risk to their business model as providing business locations is central to their product. (Please note, in addition to their Google Maps usage, Yelp also use Apple Maps for their iOS app).

So when a business risk assessor identifiers API suppliers that are crucial to their value chain, they then need to list some potential scenarios in which that access may be restricted and identify strategies that could be implemented both now (in order to reduce the future risk), and at any time the risk becomes real (in order to ensure an alternative supply source is available as quickly as possible).

RouteBuilder

Recently, RouteBuilder experienced the potential sudden loss of access to the Google Maps API. Fortunately for RouteBuilder, their app is a personal project that does not have a business model to it, and in addition, Google Maps quickly reversed their decision to restrict access. But the example highlights several issues that are worth exploring as an example of a risk management scenario that API consumers need to address in their business plans.

What Happened with RouteBuilder

Developer Andrew Martin created RouteBuilder as a personal project in 2006 after having traveled with his wife to San Francisco. They wondered how much they had walked the streets of the city by the bay, and so Martin went about building RouteBuilder to map out their pedestrian meanderings. “The ambitions for RouteBuilder were limited to creating a tool I’d find useful and sharing it with others,” Martin told ProgrammableWeb.

Today, the tool is used by hikers, bike tours, and marathon organizers. Most notably, the tool was used recently by the NAACP to guide marchers to the #JourneyforJustice march, to protest against racial profiling, police brutality and the militarization of local authorities (click on “route” in the following link to see how RouteBuilder was used.)

On January 6, the Google Maps API team wrote to Martin noting that the application used a ‘wrapper’ in contravention of the Terms of Service, and that as such, unless the app was altered to meet compliance, access to the API would be restricted.

Martin tried to contact the Google Maps team but did not receive an immediate reply, and took to Medium so he could try and engage a community to support him as the clock ticked down on his fourteen day period.

Leveraging developer community support in this way prompted the Google Maps API team to review the case again, and access was quickly restored, with Google noting that the message was sent in error and that RouteBuilder was never under threat of being closed off from API access.

What Business Can Learn From This Example

This would have no doubt been a personal blow and disheartening for Martin to see the work he started ten years ago — and that is helping fundraising activities, community organizations and recreation lovers to better plan and share their maps — come to an end, or at least require a complete overhaul in order to be maintained.

But if RouteBuilder was a business product that required using APIs from third parties in order to deliver value to customers, then the initiation of a threat to restrict API access would have larger business impacts. As DataSift saw with the removal of access to the Twitter firehose, and the confusion that Sunlight Foundation has had to endure through being denied and then re-supplied with tweets for the Politwoops data access, having ongoing access to an API is akin to a business losing a key raw material, in much the same way that a soft drink manufacturer must maintain access to aluminium for their cans, or sugar for their drinks. Lack of access to an API would mean the business would need to find a substitute API with similar capabilities, or close off features (and therefore potentially lose revenue) associated from that API-enabled service.

Mark Boyd is a ProgrammableWeb writer covering breaking news, API business strategies and models, open data, and smart cities.

Comments