Monetizing Commerce APIs [Video]

I recently had the opportunity to sit down with Matt McLarty of Layer 7 Technologies' Tech Talk Tuesday to discuss the monetization of APIs, and particularly talk about Cortex (commerce API), the first "intelligent API" for ecommerce. http://www.youtube.com/watch?v=tDMiO6D89BA&list=UUaOIRuPgP5KS7J0t0707AeA Susbcribers, can't see video? View this post on GetElastic.com

Interview highlights / summary

What is the background on the Elastic Path story with APIs?

At Elastic Path, the history and legacy of the company is the conventional ecommerce platform for retail, with a Web storefront, order capture, monetization etc. But one of the interesting things we’ve seen in our customer pool (digital content) are the things they were doing with the ecommerce platform -- moving away from the storefront, and taking that functionality they were used to (merchandising, storefront, order managment) and presenting them in different touchpoints. For example, a magazine offers subscriptions for various mobile devices, in-app purchases within software, etc. Rather than creating a shopping experience, they were taking the commerce experience and putting it in their product. This turned our paradigm of commerce upside down. In the past it was "push commerce." Take the platform, wrap an ecommerce experience around it and push it out to customers. Quite often you would hear vendors talking about a mobile shopping experience or tablet experience, that’s a push conceptualization. What we did was take a step back from push commerce, absorbing the ideas of API and taking it 180 degrees, to a commerce engine, where you do what you want, create your experience, and use the bits and pieces that you want from the commerce engine to power those experiences, through the API. There are big differences between the 2 streams of API monetization. The simpler stream dealing with content provisioning, like Facebook Open Graph or Google Maps, is relatively simple. You put a request in, you get content out. But it’s not like commerce where you have a very long use case where there are multiple steps in the flow, and authentication and security is an issue at every single step. So with our API, because we’re a commerce company, we’re not quite at the point yet where our customers would want to create public APIs. That is the next step, and we’re still conceptualizing what that business model would look like, and what are the technical issues around it. What we’re trying to do in the immediate term is to foster internal innovation to allow our customers, both within their organizations and with their trusted partners (marketing agencies, affiliates), to use the API to pull commerce into those experiences, and eventually they may open that up.

Who are the people that would use your API?

Developers in our client base and their trusted partners. Those trusted partners typically have had to make a very big investment. When you look at conventional SOAP and Restful API in a commerce engine, there’s authentication, security and issues around user flow, a lot of states to deal with, and in order to do anything with that, you really have to know the commerce system. If you are a marketing agency who wants to add a click-to-buy button within a marketing campaign, its very difficult if you look through some of the commerce platforms’ developer guides. They’re not like the Open Graph where you read a web page and fire away at it, there are literally hundreds of thousands of pages. So many calls, so many individual elements, so in order to develop against that, you really have to immerse yourself in it. We want to make it as simple as hitting up the Open Graph to build transactional ecommerce experiences. For example, you have gaming companies that have rooms full of developers, but they’re not commerce guys. And they don’t want to be commerce guys. And we don’t want to force them to be commerce guys, and we don’t want to force the company to go out and hire commerce guys in order to embed commerce into their products. So, we want to make it simple enough that as long as you have some measure of knowledge about Javascript or HTML5, you can embed commerce.

In terms of security, what do you see as the main needs around security, how do you make it secure enough without dissuading people from using it?

With commerce, it’s all about who you are and what you do. It’s all about authentication, and what kind of use cases you can do at a certain point in your flow. If you think about the conventional way, exposing the internal processes, trying to build security around that is a nightmare. You either have to secure each individual service point way down in your platform, or else you have to build a proprietary layer that’s a middleware security layer to authenticate before you get access. With our API, there’s a central integration point where everybody hits up. It’s form based, requesting access to individual services at any given time, and every element in the protocol is authenticated with a user ID.

What are the main focus areas that you have right now, are there particular audiences you’re going after? Or components of your API you want to offer up to the world?

We have a couple of focuses. The first is scalability. Some of our customers deal with pretty high traffic volumes and the issues around scalability are different from a content API -- you’re not trying to push vast amounts of data through the API. It’s more about handling the traditional traffic issues of ecommerce, and transactions through the API. Another focus is the ability to package up all the different types of features one would traditionally find in an ecommerce platform, and exposing them through the API. Not just 1 or 2 use cases. You can go into dozens or hundreds, whether looking up entitlements, placing an order, or going through order history, streamlining them through the API, without making it a monolithic chunk. There’s always issues around versioning, and making sure that the API remains consistent even as the features and functionality evolve beneath it. You may add new payment methods, or have new merchandising rules. We want to disconnect the operations of the API from the functions underneath it so that it won’t suddenly break, but it will evolve gracefully.

With regards to monetization, for your clients who utilize APIs, how are they making money?

It's a two-step process. First, the transition to an API-based strategy to grow transactional business. We do see increases in conversion and average order values when you start shifting from the Web storefront to new touchpoints (in a game, using software, etc). Making it easy for customers to spend money whatever they happen to be doing is the first benefit of moving to an API strategy. The second step is moving towards a more open model, where certain aspects of commerce functionality may be opened up to the “public” (though I don’t think ecommerce APIs can l ever be completely open). But it will allow partners and affiliates to link in and maybe not place an order, and look up things like entitlements and authentication. For example, if you were watching a movie on US Airlines, you paid your $5.99 to watch but didn’t finish it, you would be able to complete in your hotel through Lodgenet through an API enabled partnership. It could use the API to look up and see you have another 48 hours to watch it and pick up at the point you left off on the plane.

Are your current APIs an evolution from where you started, or did you have to go back to basics?

All ecommerce platforms since the beginning have had to have some form of Web services available, some combination of SOAP or early attempts at Restful APIs. You always had to integrate with catalog, inventory systems, fulfillment systems, etc. The use cases for this are very different than what we’ve been talking about. They’re all internal, they’re secured behind a firewall. We started looking at how an API can enable the consumer side, and there really wasn’t anything in the market. We really started on a blank page to conceptualize.

Do you have a strategy around versioning? How do you distinguish between versions today?

The general strategy is to maintain the front-end side, without versioning to maintain backwards compatibility. It's a strategy of isolating the business logic and the data objects underneath from the consumption and service side of the API.

What are the benefits of Level 3 REST (for non-technical, business guys?)

It's always about increasing revenues and lowering costs. If you think about the time, effort and money spent doing integrations, when you create and API-as-a-product type strategy, the integration is the most important thing -- that's what your product is. If the effort to integrate is too great, there's no ROI there. Being able to deliver really advanced services that would typically involve crazy amounts of effort very quickly is huge. We're starting to see concrete examples of this. Working with potential partners, giving them access to an API server, we've seen incredible results. Without any knowledge of our platform, being able to develop a commerce enabled click-to-buy into their product within a week or two with a very small development team, in one or two meetings. We don't have a manual yet -- one of the key elements of Level 3 REST is discoverability, everything is self-contained within the API payload. When you multiply that by all of the touch points that you need to be in, how much is it going to cost you to get senior developers that know commerce do something as basic as put a buy button on your Facebook store, and then your Android app, and then your iOS app, and then your HTML5 web app, versus Level 3 REST, where a junior Java developer could go ahead, stick that buy button in there and you're done. For more information on the Elastic Path Cortex API, visit Elastic Path. Tech Talk Tuesday is live on Facebook and Twitter every other Tuesday. For more information, visit Layer 7 on Facebook.