Bruno Pedro

Should you Control How your Public API is Used?

2014-10-01

8 min read 

This post was originally published on the Nordic APIs blog as “Should you Control How your Public API is Used?”. The more open your public API is the more developers will implement different types of applications. Some of these, however, might be ones that you would prefer not to be associated with your brand. What is the right balance between openness and governance? Should you relinquish some control to get some more users? Should you worry about how your API is being consumed? How much can you control access without losing interest from talented, outside innovators? Read on to find answers to these and other questions!

Consider the Business Implications of Apps #

Firstly, you need to determine the important success factors for your business’ API. You need to consider how these can be affected, both positively and negatively, by third-party applications and their behavior. These factors span a wide range, and you need to weigh in such things as:

To determine if and how you should control access to your public API, you need to consider the implications of these factors from the business’ perspective. To gain this point of view, let’s look at a couple of these issues more closely. Then, we’ll get back to that question of whether or not you should govern API consumption.

Third-party Apps Directly Competing #

Having a direct competitor use your API is a difficult threat to mitigate. There are two possible scenarios (depending on if this is handled in your API terms and conditions):

If use of your API in a competitive manner is strictly prohibited in your API terms and conditions, you might be able to legally act against an offending consumer. Usually, a cease and desist letter will be enough to stave off the threat. If you use this method, however, remember that the developer might replace your API with another or might create their own alternative. If this is the case, your API may have only been necessary as your competitor ramped up their app’s usage. Be sure to think about how this scenario can be disallowed and avoided when crafting your terms and conditions.

If your usage agreement does not account for competitive usage scenarios, on the other hand, update it right away to disallow competitors to use your own resources against you! Then, let developers know that your terms of usage have changed and that competitive usage will no longer be tolerated. Otherwise, it will be difficult to control this undesired behavior.

Incorrect Trademark Usage #

Another danger to consider when exposing data to third-party API consumers is the possibility that they may misuse your trademark. This can happen for several reasons:

This has happened with some third-party Twitter applications that used the word “twitter” and “tweet” as part of their name. This created confusion in the market because end users didn’t know if the apps were endorsed or made by Twitter. The social network has clamped down on this in an effort to correct the market’s perception and avoid future confusion.

Third-party App Conflicting with your Terms and Conditions #

This is something that happens more often than you may expect. Developers find that they can use your API to access some information or perform an action, but they do so without regard to your terms and conditions. An example of this behavior is when an API lets you access user-related information and clearly states that you cannot store it or use it for a different purpose. Some developers will use this to obtain information about a vast number of users, store it, and reuse it later on in another application.

Understanding if a developer is not abiding by your terms and conditions isn’t straightforward unless they publish an app and there’s an exposed feature that lets you identify this disallowed behavior. If this is the case, you should be able to get in touch with the developer and ask them to change that specific feature. If this is not the case, there are other ways of detecting misbehavior. By capturing API usage for individual clients, you’ll be able to understand which endpoints are consumed and with what frequency. If a single developer is calling an API that lets them obtain some specific information and at a very high rate, it might indicate that they are making these calls to an improper end. Finding these sort of clues of misuse is another reason that you need to be exploring API management.

To Control or Not to Control Access #

Having delved into some of the consequences of open API access, we come back to our question: Should you control access to your API? For most, the answer is yes, at least to the degree that the business’ success criteria for the API are bolstered and not impeded. What then should you do to prevent competition, violations of your terms of use, infringements of your intellectual property right, and other negative side effects of opening up your core? To start with, you should ensure that your API is accompanied by thorough terms and conditions. You should also provide clear and concise branding and User Experience (UX) guidelines.

Strict API Terms and Conditions #

To properly protect you business against misuse and potential damage, you should pay special attention to your API’s terms and conditions. If possible, hire a lawyer to help in this. Even with a lawyer’s aid though, we recommend that you first look at the Swedish API License; it will allow you to generate an API license by answering a few questions. The wizard will guide through topics such as IP rights, trademark, technical limitations, payments, and commercial use. In the end, you’ll have an API license that can easily be customized to your own needs. This is a great starting point to go to an attorney and get some help adapting it more precisely to your situation and to the laws of your country.

A good example of a tight terms of service document is the one provided by OpenFDA. OpenFDA is an initiative of the US Food and Drug Administration’s Office of Informatics and Technology Innovation that offers easy access to public FDA data. They provide APIs that lets you access structured information about adverse events, drug product labeling, and recall enforcement reports.

Even though they’re very open about data rights and usage, they clearly state that they can limit the API access, number of calls, or usage in order to prevent abuse. Another interesting point on their terms is how they protect themselves against possible third-party damages; they clearly state that they make “no warranties about the work, and disclaim liability for all uses of the work, to the fullest extent permitted by applicable law.”

Even if developers follow everything in your license agreement, there’s no guarantee that the final, end user will experience the third-party app in the best possible way. So, how do you control the end user experience? You can’t entirely, but you can certainly influence how third-party developers create their apps by guiding them.

This is exactly how Apple has been dealing with third-party API consumers. Nitin Ganatra, who used to work for Apple, says that “even in a case where a developer is knowingly not doing the right thing for one of their own customers, it’s still, to that customer, going to look like an Apple problem.” This approach makes Apple look at APIs with a different mindset, providing UX-related guidelines to developers so they can offer the best possible experience to their app’s users.

Fostering Innovation #

After all of these control-related actions, what can you do to promote interesting and innovative ways of using your API? If you clamp down too hard, developers won’t be able to innovate. If you open up too much though, you might expose the company to unwanted risks.

One way to control your API and open it at the same time is to provide two different API versions, one which is the official, production release and another one which is the bleeding edge release. Developers consuming the first one need to follow the official terms and conditions. Those consuming your beta release will follow a different license that lets them experiment in a more open way. With this approach, you’ll be able to keep your users and production developers happy while fostering innovation and gaining knowledge from unexpected uses of your bleeding edge API. You’ll be able to learn from these innovative uses and eventually incorporate new features into the official release.

Conclusion #

From incorrect trademark usage to direct competition from third-party API consumers to the other threats we’ve discussed, there are several risks that you must be aware of when exposing a public API. You should be able to control some of these with a strict API license that protects your business and its intellectual property rights. Even with the best terms and conditions, however, you won’t be able to directly control how end users will experience the apps created by third-parties. To influence this as much as possible, you should provide concise UX guidelines and promote them heavily. Even with these controls in place, outside developers will be able to use your API in innovative ways. They will be able to co-create with you and deliver value atop your API.