I spoke with Andrew Noonan, Partner Engineer at Uber. He shared the evolution of the company’s API, from its humble beginnings to a full-featured platform that lets developers build entirely new experiences for Uber riders. We also discussed a systematic approach to building an API platform that incentivizes developers.
How did the Uber API get started?
The platform started out with a simple API. You could get available products at a location and time and price estimates, but developers would need to deep link into our mobile app for ride requests.
Quickly, there was interest from developers to do more with Uber in their apps. As a result, we launched the ride request API.
That allowed developers to recreate more of the Uber experience, even without their users downloading our app. We’ve been making more and more investments along that path — making account creation through the developer platform a bit more seamless and really trying to expose all the utility of the Uber app via the API.
How do you approach the API as a platform?
We believe three pillars are necessary for any developer platform: utility, revenue and distribution.
Utility means using Uber to make your app better and more useful for your users. Because we’re a transactional service, we can expose all the utility of Uber without being afraid of developers recreating the Uber experience. As long as it holds up to the standards that our customers expect, any app can have an Uber mode.
Regarding revenue, it’s no secret — if you’re asking developers to write apps using your platform, they have to be able to pay the bills. We launched the API with the affiliate program, which gives developers $5 for every new rider they sign up. We have other ideas in the works. There has to be a real opportunity for them to make money.
If you’re asking developers to write apps using your platform, they have to be able to pay the bills.
Finally, if the developer building an app on your platform does have a business model, additional distribution is important. Trip experiences is our first big commitment into the second and third pillars of the developer platform.
It’s opening up access to a resource within Uber that we are not domain experts on and we’re not going to specifically capitalize on it ourselves. We’re not content producers; we’re not a deals website; we’re not a gaming company. We’d rather expose that via an API and let people build and iterate on top of it.
Tell me more about how you approached revenue from the beginning.
We look at the API as being a growth factor for the company in both established and emerging markets. The affiliate program was the right thing for us to do, both for Uber and for developers. We want to get new users on the platform and developers deserve the incentive.
We’ve seen it be successful for partners and it’s something we’ll continue to do, but we’re looking for more creative ways to provide revenue, too. Referring a rider is a great step, but we think that developers have the opportunity to drive real value for our riders. We will do what we can to promote that kind of innovation on our platform. Providing user growth opportunities can be a very powerful thing.
What are some examples of apps built on the Uber API?
We have some huge integrations like Baidu Maps in China. They have a full request to ride integration built on top of the API. Facebook Messenger is another big one. United Airlines is a great example of a top partner that was with us from the beginning and built on top of the early API and included deep linking into our apps.
In India, we had a partner launch that has been driving a significant amount of ride traffic called Helpchat. It’s basically a chat assistant that can order an Uber. We’re seeing this style of integration more and more.
Also, I’ve seen a couple of integrations at hackathons to order a ride via an SMS or over the phone. These apps help people who don’t have a smartphone but want to be able to call and get an Uber. They can set up all the authentication on the desktop and get a static phone number to call with a pin code. They can say where they are and an Uber will be sent to them.
How have you grown your developer community?
There’s a huge amount of interest out there and we would like to grow that interest and really cultivate it. We communicate via email and Twitter. We want to be very responsive and stay in-touch with the community — actually be there, listening to them, responding to their feedback.
Partner engineering is built into the engineering organization. I sit next to all the engineers building the API and can contribute production code. As a team, we value developer feedback highly and work on ways we can make that a zero-hop feedback-loop.
To help address this, we encourage engineers on the Developer Platform team to be part-time developer advocates. It’s a self-selecting group because the engineers interested in building the external API are engineers interested in going to hackathons and connecting with developers. We’ve been to hackathons and around the world to get people interested and make sure that we hear from them.
How have you scaled the API?
Having partners like Baidu forces us to think on a massive scale. We’ve been at a very steady pace of onboarding new developers and all kinds of integrations. There are tens of thousands of apps on the platform and it’s growing rapidly every day. It’s accelerating more than we’ve ever seen.
Uber has an awesome infrastructure and operations team that helps with some of the management of our web servers. From an architecture standpoint, a couple of things that are pretty important to our scale is intelligent caching and microservices. Uber’s backend is broken down into microservices that talk through a couple of different protocols. We open sourced a very efficient protocol called TChannel.
I’d say that those microservices are really what enable us to be so scalable. We focus on optimizing each one and then we make many calls in parallel. We’re never blocking on a series of services to give us an answer on something. Caching at the API layer allows us to limit the number of things we have to look up during a single request.