Last week, UrbanHail, a Boston startup which developed an app to provide real-time price comparisons for Uber, Lyft and taxi services, found its access to the Uber API revoked for violating Uber's terms of service. Uber forbids developers from using the API or data obtained through the API in an app that "includes, features, endorses, or otherwise supports in any way a third party that provides services competitive to Uber's products and services, as determined in our sole discretion." Uber's developer documentation specifically states that price comparison functionality violates these terms.
UrbanHail, which was created by Harvard Business School (HBS) students, claims that Uber's restrictions are "anti-competitive," and Harvard Business School assistant professor Ben Edelman, a frequent commentator on digital law, agrees.
In an article entitled How Uber Uses API Restrictions to Block Price Comparison and Impede Competition, Edelman goes so far as to suggest that Uber's behavior might be illegal.
Most recently, the FTC brought suit against McWane, the dominant US pipe fitting supplier, which had controversially required distributors to sell only its products, and not products from competitors, by threatening forfeiture of rebates and perhaps loss of access to any McWane products at all. The FTC found that McWane's exclusionary distribution policy maintained its monopoly power; the Eleventh Circuit upheld the FTC's finding; and the Supreme Court declined to hear the case. McWane thus confirms the competition concerns resulting from exclusive contracts from distributors. In relevant respects, the parallels between Uber and McWane are striking: Both companies use contracts to raise rivals' costs to prevent them from growing into effective competitors. Compared to McWane, Uber's API restrictions are in notable respects more aggressive. For example, McWane's first response to a noncompliant distributor was to withhold rebates, and in litigation McWane protested that its practice was not literally exclusive dealing but rather a procompetitive inducement (through rebates yielding lower prices). Putting aside McWane's failure in these arguments, Uber could make no such claims, as its API restrictions (and threats to UrbanHail, discussed below) exactly implement exclusive dealing, expelling the noncompliant app or site from access to Uber's API as a penalty for including competitors.
Edelman also argues that Uber's restrictions could violate the Sherman Act, the key antitrust law in the United States:
More generally, Uber's conduct falls within the general sphere of exclusionary conduct which has been amply explored through decades of caselaw and commentary. The Department of Justice's 2009 guidance on Single-Firm Conduct Under Section 2 of the Sherman Act is broadly on point and usefully surveys relevant doctrines. As the DOJ points out, the essential question for exclusionary conduct cases is whether a given tactic is appropriate, aggressive competition (which competition policy sensibly allows) versus a practice intended to exclude competition (more likely to be prohibited under competition law).
So are Edelman's arguments convincing?
Edelman himself notes that "one doesn't readily find antitrust cases about APIs or facilitating price comparison." The McWane case he cites involved "distributors" responsible for selling a product to end customers. Are developers who build apps that integrate with the Uber API similarly "distributors"? That seems highly debatable.
While Uber is a private company and its financials are not publicly known, it is all but certain that the vast majority of Uber rides are booked through Uber's own apps, not third-party apps. In other words, Uber is the primary distributor of its own services to end customers.
What's more, when it comes to those third-party apps, the developers behind them can't earn money for rides booked in their apps. Uber does pay a bounty of $5 for new customer signups through its affiliate program, which developers can participate in, but developers don't profit directly for allowing Uber customers to hail rides in their apps, nor do they handle any of the money in the transactions that originate in their apps.
Perhaps because of this, the highest profile Uber API integrations, which include the OpenTable, United Airlines and Hilton HHonors mobile apps, involve companies that aren't in the ride-sharing business and which have clearly added an Uber integration to their apps for the convenience of their customers, not to build a new business or expand an existing one.
But even if developers are to be considered "distributors" in the 21st century economy, an even bigger problem with Edelman's anti-trust arguments would seem to be the fact that Uber doesn't have a monopoly. Yes, the company has disrupted the taxi business, and is huge and growing, but it doesn't have monopoly power in any conceivable market. Edelman himself acknowledges this, writing "Uber might argue that it is one of many transportation services and that the Sherman Act should not apply given Uber's small position in a large transport market." He suggests that "as the leading app-based vehicle dispatch service, Uber would certainly be found a dominant firm in such a market" but even in a hypothetical app-based vehicle dispatch market, Uber has real competition from companies like Lyft.
As far as Uber is concerned, it has the right to determine how its public API is used. An Uber spokeswoman told ProgrammableWeb that "thousands of developers around the world have used the Uber API to build new, interesting apps. We have an API with a few guardrails in order preserve the integrity of the Uber experience for users across all apps."
The spokeswoman pointed to apps created by developers, including a scheduling app developed by a Harvard sophomore, that don't violate Uber's terms. She said the company attempted to contact UrbanHail about its use of the Uber API, but did not receive a response.
Anti-trust and APIs
While the risk of regulatory action focused on API restrictions would seem to be minimal at this point, Edelman's analysis does raise questions about how such action could impact the API economy in the years to come.
As Edelman sees it, "Uber would face little burden in being required to provide data about its prices and availability to comparison services; Uber has already built the software interface to provide this data, and the servers are by all indications capacious and reliable. Enforcement would be easy: Require Uber to strike the offending provisions from its API Terms and Conditions. Uber need not create any new software interfaces or APIs in order to comply; only Uber's lawyers, but not Uber's developers, would need take action."
While there's a legitimate debate to be had over whether companies like Uber should support use cases such as price comparison apps, if Edelman's logic is ever accepted as valid in the context of legal or regulatory action, it could set a dangerous precedent for the API economy. After all, Uber, like many other companies that offer public APIs, probably doesn't need a public API to survive and thrive.
If large companies are unable to set restrictions on how third parties use their APIs, and can be forced to make their data public for any use because the software interfaces to distribute it are "already built," many companies would be disincentivized from building APIs in the first place lest they be told by attorneys and bureaucrats what to do with them.
Given just how big a role APIs play in the internet economy today, that outcome would inevitably hurt consumers a lot more than allowing companies to decide how their APIs are used by others.