Did this Public API AntiTrust Case Set Precedent for Uber?

Can you have a public API but put restrictions on it? Well, we assume that’s what terms and conditions were made for. But, to what extent must those terms and conditions comply with antitrust law? Or, at least allow for competitive applications of your API if your company doesn’t qualify as a monopoly? Can your application programming interfaces truly be “public” if your terms and conditions disallow application contexts deemed to be competitive to your business interests?

These are the questions coming up in the API legal space, most notably with Uber, which, for one developer, has withdrawn access to its API based on terms and conditions that some view as an illegal effort to lock out the competitors. However, the lawsuit-ridden San-Fran-based online transportation network company may see a silver lining in last month’s North Carolina Superior Court’s dismissal of SiteLink Software, LLC v. Red Nova Labs, Inc. in which similar issues are covered

Today we will talk about this new ruling and how it may or may not help secure Uber’s ability to have a selectively public API.

How SiteLink v. Red Nova Secures Control Over Public APIs

There’s no doubt that the self-storage industry has received a lot of press and influx of money over the last few years after cable TV’s competitive reality shows like Storage Wars. And, like any old-fashioned industry, the self-storage industry is embracing the way technology and APIs can help it grow. But this has left two facility management technology companies having their own storage war over access to one API.

SiteLink Software offers a partner ecommerce API that  provides access to real-time storage facility management data to developers of complementary solutions. For example, through SiteLink’s APIs, developers of storage facility websites can incorporate SiteLink’s ecommerce and back-office capabilities. Red Nova Labs is a company that builds websites for self-storage facilities that, in recent years, decided to offer its own facility management software (FMS). According to the court opinion, SiteLink as market leader has about 11,000 customers — or more than a third of the available market — while, according to its website, Red Nova has only about 2,000 customers.

As complementary offerings in 2012, the two companies were partners not competitors, with about 40 percent of Red Nova’s customers also being SiteLink’s customers. But, in 2013, after SiteLink allegedly turned-down Red Nova’ request for a FMS partnership, Red Nova developed its own storage facility management software offering.

In April 2014, SiteLink modified its API licensing terms to state that an API user shall “not compete directly, or through an affiliate company, or through...related third party with SiteLink,” or “operate in conflict of interest to SiteLink, or in a manner detrimental to the reasonable business interests of SiteLink, or in conflict with the services provided by SiteLink.”

Essentially, SiteLink fashioned new terms of service that prevented developers from using its API  if those developers had also purchased or used competing services  in the self-storage industry, which, since 2013, included Red Nova. In January 2014, SiteLink not only revoked Red Nova’s access to its API, but also sent letters to those overlapping customers that they could only continue to use SiteLink if they switched to a list of other website providers and stopped using Red Nova.

It appears that SiteLink made this change specifically to restrict Red Nova’s access to customers, which indeed it did.

SiteLink says that Red Nova broke its API licensing terms by competing with SiteLink and using the API at the same time, while Red Nova says that SiteLink’s API licensing agreement imposes trade restraints that are in violation of the State of North Carolina’s Chapter 75 antitrust law. SiteLink is a North Carolina company.

In addition, Red Nova complained that SiteLink uses these licenses to maintain an “unlawful anticompetitive advantage and to forestall Red Nova’s ability to compete with SiteLink.”

Did the Court’s Findings set API Precedent?

SiteLink won this dismissal by a long shot in a very strong opinion by Superior Court Judge James L. Gale.

Since the 1985 North Carolina Supreme Court case of Oates v. JAG, Inc, the state court has had a very stringent mandate to dismiss a case if any of these three things are true:

  1. No law supports the plaintiff’s claim
  2. Complaint does not plead sufficient facts to state a legally sound claim
  3. The complaint discloses a fact that defeats the plaintiff’s claim.

Judge Gale believes that Red Nova failed to offer enough facts — including that it did not list any of the customers it had lost — and thus it did not offer an actionable antitrust claim.

Be sure to read the next Law article: Why Not to Overreact to Facebook's React Patents License


Comments (5)



Thanks for the article and surfacing this legal case.  I read the courts opinion (thanks for the link btw, I'd have never found it) and was struck by something I found missing.  There's no mention in the opinion of the fact that SiteLink likely had one 'terms of use' when RedNova started developing against the API, and then changed those TOU when they found out about the competiting product.   While RedNova failed to substantiate a number of the foundational claims to their argument (monopoly being the big one), which undermined their entire claim, it does seem that the change to TOU specifically to target one user is a bit suspect legally.   In other words, if SiteLink had been deemed to have monopolistic power, and changed TOU to target a new competitor, and the competitor could prove fiscal impact (which it seems RedNova could not), then I wonder if things might have ended differently.  I guess the bottom line takeway for me is for enterprises to really think through the business, market, and comptitive context for their Public API's before publishing them.  While TOU's can always change, an API owner would want to avoide these situations where possible.   I also think that UBER is still open to challenge on UrbanHail.  Bottom line is that public API publishers should get good legal and business review on their TOU prior to publishing.    


Is Uber's API a public API? Do they say it's a public API? What definition of public API are we using here, and what would the legal definition of a public API be? And if those differed, what would be the legal implications of the terms attached to them, and the monopolistic powers those terms can and can't have?

I'd offer that the Uber API isn't a public API, and I don't think they've ever used that term. It's a Partner API that you can register for on their publicly available website (the use of the website, though, also carries terms). By so doing you enter into a partnership agreement with them, the terms of which are very well defined. There are certainly different levels of agreements and relationships, and different terms that come with those, as well. There is a license to use the API, and there also ought to be a license dictating what can be done with the data received from the API (which is not the same thing as using the API). 

There would definitely be far reaching implications for APIs. I don't think I've seen an API agreement without some form of this "you shall not compete or enable competing" by means of this API. I think the API economy would pull back from have public web access to the registration and documentation for their APIs if this was found to be a problem, since they certainly wouldn't just allow it widespread. That might run counter to what many engineers think an API is supposed to be, but an API in this context isn't really for engineers. It's for business.


I think what they have isn’t a public API, it’s a Partner API that has a sign up form on a public website. Even that public website has a TOS attached to its use. I'm pretty sure Uber doesn't call their API a public API, and the definitions of a Public API (as opposed to a Partner API, or other types) is still pretty nebulous-- yet carries significant weight in people's minds.

I think we ought to have (and often do have) terms that govern the use of an API, and terms that govern the data you get from an API (which isn’t the same as using the API). All data carries terms of use about what can be done with that data. There is no world where there aren't terms attached in a business-provided piece of data.

If Uber was found to be acting anti-competitive here, as a rule I would think most business would pull back from offering sign up for and documenting APIs on publicly available websites. I’ve never met an API provider who didn’t put some version of “don’t compete with us” in their API terms. It’s not going to be as simple as removing the terms-- it removes a material protection that makes a business comfortable offering their data and behavior through an API.

As a generalization, engineers don’t want to be constrained by business and legal terms. Just because an API enables them to do something doesn’t mean they should build that thing they want. The trend will be to remove the API and remove the ability to build it, not to change the terms to be more permissive.


I would frankly like to sue Instagram for its anti competitive api permissions review; despite the fact that an application mirrors the funcationality of other applications that have seemingly been granted the requested permissions based on their stated performance, Instagram denies the requested permissions and thereby monopolizes and controls the competitive landscape among apps that use the api.


I frankly would like to sue Instagram for its arbitrary and anticompetitive permissions review process. Despite the development of an application that mirrors applications that would seemingly have been granted the requested permissions, Instagram will deny the request for unspecified and clearly inapplicable reasons--that the application does not fall into a permitted use category, even though it clearly does. In doing so, Instagram is defeating and controlling competition in the application space.