API Terms and Conditions Done Right

This guest post comes from Steven Willmott. Steven is the CEO of 3scale networks, a company that provides infrastructure services for a wide variety of APIs.

One of the questions we are often asked at 3scale (a ProgrammableWeb sponsor) is around legal terms and conditions (T&Cs) – once we have all the technical stuff, what should we put in the API terms and conditions? Should they be different from our web site terms and conditions? What will the impact of certain clauses be? Since we’re not a law firm, we generally can’t answer this question in detail but there are a few recurring themes we often see in T&Cs that seem worth sharing.  The content of this post should not be taken as legal advice in any way, but hopefully it provides some useful things to consider.

The most important thing to bear in mind is that your T&Cs are one of the most important parts of your relationship with developers, customers and partners who will be using the API. Mess this up and you may see very low adoption, change them too frequently and you may get developer outrage – see the need for Stephen O’Grady’s post on the need for a Mashup Developer Bill of Rights and YourTrove’s developer pain points survey for example – tread with care!

API T&Cs will often be tightly linked to the terms already set for the web versions of a service where they exist since the API will likely allow access to much of the same functionality. We commonly see companies binding API users to both the service T&Cs as well as API specific terms.

Assuming this is the case, here are some of the most common API specific additions we see:

  • Downtime clauses and Service Level Agreements (SLAs): for an API to be useful it needs to be available when developer applications call – this makes uptime guarantees (and uptime record) an important consideration for developers. However, providing uptime guarantees can also lead to significant economic risk as the value of applications built on the API increases. Hence the T&Cs should state whether or not the API is “as is / best effort” (no liability for downtime) or if guarantees of some kind are provided. They should also state what economic recompense if any there is and how it would be limited. Different API audiences will require different levels of guarantees but a common pattern is to have “standard” access to an API clearly defined as “best effort” with no liability for downtime or unexpected changes (or even withdrawal of the service), but offer higher cost versions of the API with set SLAs and guarantees.
  • Data Privacy: if the API can allow third parties to access personal user data, this generally requires an extension to normal data privacy terms. For example for APIs that allow third parties to develop applications which users of the service will use to access their own data then this data will most likely pass through either third party servers or code. This is true even if Authentication patterns such as openAuth are used. OpenAuth simply means username/password credentials do not need to be shared with third parties, but - once authorized - applications may still access user data and hence privacy guidelines need to strictly apply to API usage.
  • Data Caching and re-use: since APIs often allow bulk access to data, certain usage modes may allow API clients to cache significant data to avoid making too many API calls. This can be positive (and some T&Cs may in fact enforce caching), but it can also be a negative (for example, if the API charges its users by volume of API calls in which case caching disrupts the business model). The T&Cs should be clear as to whether caching is allowed, required or not allowed – which is applicable will depend on the API. What can be done with the cached data should also be covered in the T&Cs – in many cases, you may need to restrict usage of cached data to only the initial third party using the API and not permit passing this data on further to others.
  • Branding rules: many APIs are by their nature free to access, yet they still need to bring some benefit to the company providing the service. A common form of payback is to add Branding rules to the T&Cs that require developers using the API to add acknowledgements to code, web pages and in other locations. In general, the terms may read “comply with branding rules as defined elsewhere and that may change according to a specific timeframe”. Non-compliance with branding rules may then become a reason for shutting off applications.
  • Rate limits and fair use: it’s useful to include references to the existence of rate limits of fair use policies in your T&Cs. While you want others to use the API it can be challenging to provision for the many millions of transactions per day that can occur if some of the applications are successful. Developers should be made aware of the rate limits that do exist so they can plan to use the API more efficiently and not invest effort only to be burned when their applications are successful.  Rate limits are can also be used to create the potential for pricing tiers for commercial APIs.
  • API Versioning and notifications: T&Cs should ideally contain reference to the possibility that changes can be made to the API and that old versions may not be supported forever. Legal instincts would tend to make these clauses as aggressive as possible and general terms tend to allow changes with immediate effect without penalty especially for security related incidents. However, developers are very wary of the risk that this poses, so it is a good idea to try to commit to lengthy notice periods for changes to allow applications to be transitioned between API versions.
  • Kill switch provisions: similar to Rate Limiting, T&Cs generally need to include the ability for the API Provider to terminate access to applications which violate any of the other terms. This may be necessary if an application breaches privacy rules, undesirable content rules, commercial restrictions or usage limits. Restrictions on specific IP ranges or users / accounts may also need to be provided for in the terms.
  • Commercial Restrictions: lastly, depending on what the API provides, there may be certain types of applications that are not permitted. Movement allowed applications often causes significant developer frustration since banning types of applications that were previously allowed means significant development and marketing effort may have been wasted. Current T&Cs often contain a blanket clause stating that the API provider may define what is commercially permitted at any time. Whilst this may please the legal department, in practice it is important to communicate clearly and consistently what is permitted.

Often there are conflicting demands from different parts of the organization – operations teams wanting to lock down access, business development wanting to open it and the legal department nervous about the implications involved either way.

API T&Cs will no doubt evolve over time and hopefully become easier to put together and more transparent.

Remember that all the good technical work on the API might be undone by bad T&Cs if they create uncertainty and risk for the developers you hope will use the API.

Be sure to read the next Law article: "Don't Use Our Private API," They Said Snark.ly