Why APIs Are the Future of Commerce

The fundamentals of retailing remain unchanged – getting the right product, to the right person, at the right time, for the right price. How this occurs in today’s technology-driven retail environment is completely different than ever before. For example, a 2016 study by Harvard Business School showed that 73% of consumers used multiple channels during their shopping journey.

Technology and habits are quickly changing on the consumer-side, with the clear trend being toward mediation through consumer-focused platforms and electronics. Most consumers now engage with brands through a handful of social media apps on consumer electronic devices, like smartphones. With all this change on the consumer-side, the notion of what a channel is has fundamentally changed.

A channel used to be a discrete physical or virtual interaction with a customer, often through an interface that entirely consumed the customer. Examples include physical stores, websites, mobile applications, kiosks, etc. It was clear when your customer engaged with your brand. If your customer opened up your app on their smartphone, they were engaging through your mobile channel. Behind the scenes, each digital channel had its own technology stack and data. This required complex integration to synchronize order, customer and product data across all of these disparate channels. It's this type of complex integration that allows a customer to place an order on a mobile app and pick it up in a physical store, for example.

Customers’ attention is so fragmented that it’s hard for them to interact with single channels anymore. A 2016 Forrester blog post by Nicole Dvorak titled "Data Digest: Just A Handful Of Apps Account For Nearly All App Time On Smartphones" recently stated: "Today, consumers spend most of their time on smartphones using apps - and just five apps account for 88% of the time they spend using downloaded apps. For the average US smartphone owner, those apps are Facebook, YouTube, Instagram, Gmail, and FB Messenger. And although smartphone owners use about 24 unique apps in a given month, the remaining 19 command just a small slice of users' time."

Unless you're one of those five apps, you don't have much of a chance of your customers going out of their way to download and especially use your app.

Instead, you have to reach customers in dozens of smaller touchpoints. Social media (Instagram, Facebook, Pinterest, Twitter, Snapchat, YouTube, etc), wearable devices, marketplaces (eBay, Amazon, physical malls are beginning to have shoppable applications), smaller embedded “micro” applications on mobile devices (iMessage apps, etc), and so on are now the primary means of interacting with brands.

An example of today’s fragmented interactions are one of our customers – Carhartt. They use commercetools, a cloud native, API-first commerce solution to power their digital experiences. Product-related content, pricing, promotions, etc, are all accessed from commercetools as APIs:

If you're interested in learning more about how Carhartt has modernized their commerce with commercetools, we've published a nice case study.

These in-context product offers are the present and increasingly the future of retail. You have to be part of your customer’s every day lives in order to remain relevant. You have to give them contextual content in the location of their choosing. Very few brands have enough value that a consumer will consume an entire channel, like a mobile application.

To further complicate matters, there’s a revolution in consumer electronics that’s allowing customers to interface with devices in new ways that were never possible. Voice, for example, is rising in prominence. Apple’s Siri handles over 2 billion commands a week. An incredible 20% of Google searches on Android-powered handsets in the U.S. are input by voice. Amazon Echo’s were one of 2016’s hottest holiday gifts. There are also smart cars and other embedded devices that allow customers to interface with technology in ways never possible. Commerce is now as simple as saying "Alexa, buy me some AAA batteries."

Let’s look at an example. Pizza Hut has always been on the forefront of technology. They claim to have had the first online store in 1994. They were early adopters of mobile, social and now even voice-based ordering. Their business model is focused on reducing the amount of friction required to order a pizza. Here’s a timeline of the technologies they’ve adopted:

Notice how beginning in 2007, the engagement is mediated by new gatekeepers. Prior to the iPhone being introduced in 2007, consumers more or less directly interfaced with your website. It was simple – you directly interacting with your customer. Perhaps as important as the iPhone itself was the concept of the app store, where customers could download trusted apps from a walled garden. By setting standards for, reviewing, and approving apps, Apple became a mediator between you and your customer. Android adopted the same model. Social media’s rise to prominence in 2010 brought even more mediation. In 2017, you have to reach customers where they are, on their own terms through the platform of their choice. Experiences are now more and more mediated.

Mediated experiences require the use of APIs, which is why APIs are now the primary currency of commerce. Rather than build a single website or mobile app with its own stack, you should instead offer a suite of dozens, hundreds or even thousands of discrete functionality as APIs. Some of those APIs can be built in-house, some can be outsourced to a partner, and some can be purchased from 3rd parties like commercetools. What matters is that the APIs are available and easily consumable from anywhere. Websites, mobile apps, consumer electronic devices, and social media platforms can then consume those APIs to build compelling experiences for your customers, without any synchronization required of your back-end platforms because there is only one back-end that all channels access through one API. Not having to do all of his integration work saves huge amounts of time while dramatically improving flexibility.

For example - Best Buy is openly courting developers to integrate its APIs.

Additionally, Amazon.com, Walmart, Tesco, eBay, Target, and most of the world's leading retailers are on board with this trend. Jeff Bezos famously directed his staff to adopt this approach in a 2002 memo:

1. All teams will henceforth expose their data and functionality through service interfaces
2. Teams must communicate with each other through these interfaces
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn't do this will be fired

Today, Amazon famously has thousands of API endpoints which it uses to "inject" Amazon.com into thousands of different social media and consumer electronics endpoints.

Gartner’s IT Market Clock for Digital Commerce, 2016 reaffirms this trend by stating:

“Digital commerce is rapidly evolving and the future landscape will include API orientation at its core. Gartner has introduced a vision for this evolution toward commerce that “comes to you”, and commerce platforms with a full API are best placed to lead this evolution.” 

With a time to next market phase of two to five years, Gartner states that “Businesses embracing this approach will be well positioned to embrace the future API economy, conversational interfaces and other new capabilities that could confer business advantage.”

Many of today’s legacy commerce platforms were built in 1995, 1996 or 1997:

• Intershop (and later Demandware): 1995
• Microsoft Commerce Server: 1996
• IBM WebSphere Commerce: 1996
• Oracle Commerce (formerly ATG): 1997
• hybris: 1997

In the mid-late 1990’s, there was only one digital channel – the web. Apple was still in bankruptcy. Mark Zukerberg was 11 years old. Commerce platforms of that era were built to serve HTML-based web pages and nothing else. It was only in the late 2000’s and early 2010’s that the functionality these platforms retroactively exposed some functionality through APIs.

Functionality inside a large monolithic commerce platform cannot simply be exposed because the applications were written to have all of the logic within and only expose the bare minimum information to the web-based user interface. Think black box, with millions of lines of code. It was only later that some functionality was exposed as APIs. These monolithic commerce platforms were built for a specific purpose in a specific era.

In this model, APIs are modeled first (Swagger, RAML are popular):

This allows the APIs to be extremely rich with functionality. If the only means of interacting with the code is an API, and APIs are modeled first, the experience will be completely different from a monolithic application that has retroactively bolted on some APIs 15 years later.

Once the APIs are generated, language-specific stubs can be auto-generated, to match the API that was modeled.

This is exactly how we at commercetools approach commerce and it allows our customers to have the most flexibility possible.

Here's an example of our shopping cart API:

And here's how you'd query the API:

If implemented correctly by the provider, like we do at commercetools, APIs can be written in a way that they can be consumed individually. You could consume just a shopping cart API, for example. Or just the inventory API. You don't have to give your monolithic platform all of the data (customers, orders, products, etc), like you have to with current stacks. Behind the scenes, we implement these APIs as microservices, but that's for another post...

Today’s commerce platforms are expected to be API-first because APIs are the only way of injecting commerce into mediated experiences. APIs are faster to integrate, offer more flexibility, and if implemented using a microservices approach, supporting all of your future commerce initiatives.We at commercetools are the leader in this space. If you're interested in learning more, have a look at commercetools, my previous LinkedIn posts, and my book on the intersection of microservices + Commerce: Microservices for Modern Commerce (O'Reilly 2016).