Public APIs: Advice for a Producer

Many companies are trying to monetize the huge amounts of data and insights they have locked in their internal databases and creating consumable APIs for customers, partners, and the public. It seems like a great way to build revenue around that data. It’s also a great way to showcase some of the innovation that goes on in your company and with the job market as competitive as it is for employers, it’s a double win.

There are some things to consider though before just wrapping a REST API around your private data. This is not intended to be a definitive list, but rather a few things to consider before you invest in a new revenue stream.

Resources

Obviously, creating an Internet facing product requires additional resources. This can be the hardware for a server to run it on, or more likely something cloud based and possibly server-less as well. You also will also likely need security devices to ensure that access is granted securely to your API and to your potential customers. Lastly, you will need someone to build, test and assess the new system.

All of these resources cost money, and at some point you will need to pay for it. Many CIO’s have a limited “slush fund” for experimentation and this can get it started, but as it gets more expensive you are going to need to monetize it, and ensure that you have a real operational budget to continue and scale up as demand rises.

Liability

There is always a question of liability when you are providing information. How do you ensure it is accurate? And if it’s not, what are the ramifications? For example, one company I worked for used a public API to get the United States Zip Code from addresses. It was actually a great way to validate an address, or in our case avoid the customer having to enter the zip code.

However if the Zip Code is wrong, that can cause delivery issues. The package might be delayed, sent to the wrong house or sent back. In those cases, who has to cover the replacement or additional shipping costs?

It’s important to understand how the data will be used, and what challenges incorrect data will cause your customers and ensure that your terms of use, or contract clearly explain who is responsible for what.

Privacy

Privacy comes down to a few factors. Are you allowed to share the data, who are you sharing it with and what are you allowed to do with that information. The first two are pretty obvious. There are many regulations on how you can share data. GDPR is the latest, but by no means the only one to deal with that.

One thing that is often overlooked or not thought about is what to do if your competitor is using your data. For example, assume you build an address to Zip Code tool, and it’s really good. It's so good in fact that your competition uses it. That address information can be used and combined with other information to effectively learn all of your competitor’s customers. Should you? Are you allowed to? And, maybe even more fundamental what business are you in?

Breach concerns

Once you start allowing public access to your company’s information, what happens if that is compromised? What controls can you put in place, and if the data is public through your API, does it matter? This will vary greatly depending on what you are allowing access to and what value you assign to it.

Summary

Trying to leverage the work and resources that you have to create new revenue sources is a great thing.  Amazon, for example, has done pretty well with the whole “cloud thing” but it is not without risks. This article, while not a complete list, hopefully at least started some internal dialog around what sorts of concerns you need to think about.