I recently had a chance to play around with the Uber API and the experience reaffirmed my belief that Uber is pushing the API economy forward in a meaningful way, providing a roadmap for other commerce apps to follow in building out their own API programs.
First, a little history
When Uber initially opened its API to developers in late 2014, Josh Constine compared the effort to Facebook's strategy to populate the Internet with its Like buttons. "They made sharing an impulse decision," he wrote of Like buttons.
But Uber wasn't quite there yet. Unlike the Facebook API, which lets users like or share a piece of content without leaving the content, the initial release of the Uber API required all but a select few developers to deep link users into the Uber app in order for the user to complete a ride request.
All that changed early last year when Uber publicly released its Request endpoint. The endpoint allows whitelisted developers to build experiences that let users request a ride, complete a booking and track the status of their ride -- all without leaving the comfort of the originating app.
The Uber API's latest release, Trip Experiences, is perhaps the biggest game-changer, but before we dive into that feature and what it could mean for the broader API economy, it's important to fully understand how deep (or shallow) developers can go when integrating the Uber API. (Technically-inclined readers: feel free to skip ahead as certain parts of this section may seem rudimentary.)
The Car Engine
Imagine the Uber API is a car engine. Developers now have the option to install specific parts of that engine into their apps or put the entire engine in their apps and have it run on its own -- even without a user having Uber installed on their device.
Ride Request Buttons
The most basic engine part is a simple Ride Request button. When a user taps the button, they are deep-linked from the originating app into the Uber app. Developers can pass a destination address or a product ID (UberX vs. UberSelect) into Uber to save a user some time on the other end.
Product Information
The next most basic usage of the Uber API is displaying fare and time estimates inside a third-party app. Developers can use such information to build user intent, instead of blindly sending users into Uber without the user first knowing the estimated cost, pick-up times and whether there's a surge.
Request Endpoint
The Request endpoint is the figurative "full car engine". It requires that developers follow a three-step OAuth process on the back-end which ultimately returns an access token that enables developers to incorporate the entire Uber experience into their apps. Users can book, cancel and even track their ride on a map inside the third-party app.
To deliver updates to users on the status of a ride -- for example, when a ride is accepted by a driver, is arriving or is in progress -- developers can either poll the Request endpoint periodically to see if the status of a ride has changed or they can have status updates pushed to them by setting a webhook that automatically alerts the app when a ride's status has changed.
Trip Experiences
Okay, here's where things get cool.
As a developer, I can now know in near real-time if one of my users is currently taking an Uber, where they are headed and when they will arrive, regardless of whether the user requested the ride from within my app.
Users must first authorize the app developer to access such information in the same way users authorize apps to make ride requests on their behalf. Once permission is granted, knowing where one of your users is headed and when they'll arrive allows developers to predict what their users might want.
For example, say I'm the developer of a local discovery app like Spot and a user opens my app while they're waiting for a ride or while their ride is in progress. Spot could save users time by showing venue suggestions or offers in the vicinity of their destination.
Or, some enterprising developer could integrate the Uber API and the Facebook API to alert a user to the fact that they are riding in an UberPool with someone whom they share mutual friends with. Finally, an icebreaker on those awkward rides!
But let's dial it back a bit and return to the larger point: A host of commerce apps -- including services like Airbnb, OpenTable and Kayak -- should mimic Uber's efforts to build and release an API that is easy to hack on and also offers developers incentives to integrate, such as bounties for new sign-ups, or the ability to customize experiences based on actions a user has taken outside their app.
Airbnb, for instance, should know that I just booked a trip to Los Angeles on Kayak so it can suggest places I might want to stay in the area.
Some commerce apps have already followed suit: See Lyft's recently released API or the Postmates API.
Others have taken a more guarded approach to releasing their APIs by first partnering with companies that make their content available to third-party developers via pre-built UIs.
Airbnb, for instance, partnered with my former employer, URX, to render its listings within a carousel UI on the mobile sites of various travel and local publications. When a user is reading an article about New York City on Travel & Leisure, the integration detects "New York City" on page-load and renders Airbnb listings in NYC.
Another example is OpenTable, which makes its reservations available inside the Foursquare app through a partnership with Button, a startup that focuses largely on driving commerce between native apps (as opposed to URX's focus on driving commerce between mobile sites and native apps).
The next step is for companies like Airbnb and OpenTable to go all in on the API economy by launching developer platforms of their own.
On such platforms, developers might do as little as generate code snippets for pre-built UIs that render product-level information or as much as build deep API integrations that let their users browse third-party content and complete actions -- like booking a room or making a reservation -- without sending users outside their app.
Messaging apps and the emergence of "conversational commerce" offer a glimpse into this future state. For example, check out Operator, a personal assistant app based entirely on a messaging interface. Operator's messages can include a rich card with a carousel to scroll through product results and a buy button on each result that immediately triggers a payment flow.
While Operator doesn't currently show Airbnb listings, one can imagine that we'll soon see integrations of services like Airbnb, OpenTable and Kayak in messaging apps (see Messenger's upcoming announcement, Kayak's recently launched Slackbot and an Airbnb Slackbot I built earlier this year) and beyond.
Part of the reason conversational commerce has created such a stir this year is because it caused us to finally wake up to the fact that apps are just containers around web-like backends. If given the right tools, we can strip apps down to their core -- the API -- and insert them into interfaces as simple as a text message.
I'm sure we'll see more apps investing in smart API programs, as Uber and others have done, in order to drive sign-ups and transaction volume from within other apps in the U.S. and abroad.