Loading Form...
Aug 25, 2021 | 16 minute read
written by Jeffrey Wright
If you are looking to differentiate or solve unique and complex eCommerce strategies, then you are likely looking at Headless Commerce approaches. This also means, you are getting up to speed on API business models and the many eCommerce use cases they enable. APIs can be described as the connective tissue that enables a multi-solution architecture to deliver business value.
However, with composable, microservice-based architectures it goes beyond simply enabling your next eCommerce use case and into a “future proof” strategy that unlocks infinite flexibility that can quickly adapt to changes in buyer behavior and expectations. Couple that with the fact every new generation of buyer is more and more tech-integrated with how they live their lives, this future proofing concept is more critical than ever for eCommerce leaders to explore when evaluating commerce technology.
API business models define how companies make money from using APIs. So as an eCommerce manager you are likely looking to design an architecture using multiple solutions that use APIs in different ways to make money. Understanding how API business models work, should give you a good perspective on how different vendors price their technology or services so that you can create a business plan for how you want to invest in solutions and potentially enable your architecture to participate in the API market.
The biggest challenge is how fast API business models are evolving. Back in 2013, we explored API business models in a blog titled, "18 API Business Models Deconstructed," which was based on a presentation called "Open APIs: What's Hot, What's Not?" by John Musser of ProgrammableWeb. Back then Mr. Musser explored 18 different business models that are built off 4 core API revenue approaches - Free, Developer Pays, Developer Gets Paid and Indirect - see below the visual hierarchy:
Last year, ProgrammableWeb published a revised report where they expanded the model to include 40 API business models and a revised hierarchy that moved away from the 4 revenue approaches and instead based it on Internal vs. External business models + an Outlier group, which I am sure will be the basis for this model to expand in the coming years. With so many eCommerce buyers researching whether Headless Commerce solutions is the right investment, we thought it would be a good idea to review the latest report and further examine how APIs are playing an ever-increasing role in developing a best-in-class eCommerce business model.
If you want to review the full 2020 report from ProgrammableWeb you can read the summary and download the full PDF from their site here.
To contrast the 2012 report, below is the new hierarchy visual of the 40 API business models. In our article today, we are not going to review all 40 API business models in detail, but instead focus on the ones that have the most relevancy to eCommerce use cases.
Since the hierarchy has changed, maybe we first define the two top branches of the model. As explained by David Berlind, Editor in Chief, ProgrammableWeb, in the 2020 report, the top of the hierarchy - internal and external APIs - are not synonymous with Private vs. Public APIs. For example, an API that is used to connect your eCommerce platform with a 3rd party payment provider is external but is most definitely not public (which tends to define APIs made available to any developer, anywhere, regardless of source).
The way to think about internal vs. external is within the context of firewalls and hosting. If you are connecting systems together within your corporate firewall, then you are using internal API business models and if you are connecting an application/platform to a 3rd party or externally hosted service or application, then you are using external API business models. Another way to think about it is all public APIs are external, but not all external APIs are public, and all internal APIs are private.
eCommerce experts we speak with tell us more and more that one of the primary goals of their eCommerce strategy is to "future proof" their eCommerce investment. That means most eCommerce leaders are getting up to speed quickly and putting together a business plan for how to move to a headless, API-first solution. However, to gain the efficiencies and effectiveness of an API-first architecture, you need to think about how you want to enable your business using technology and how that can affect your eCommerce use cases in the short, medium, and long term. For example, if you are exploring the business value of deploying a composable, API-first architecture to enable your eCommerce goals, then you likely will be investing in cornerstone technology that uses external API business models which you will then integrate with internal systems that you want to re-use as an MVP approach.
One of the most compelling use cases for moving to an API-first architecture I read about during the pandemic was from Best Buy. Best Buy had made the decision back in 2011 to enable BOPIS (buy online, pick up in store) to help create a competitive differentiator. This required a re-platform of their legacy monolithic architecture to an API-first headless architecture. The goal back then was to stay competitive with the pressures of Amazon, but I would love to know if at the time they realized how much of a “future proof” architecture they were creating. No one could predict the pandemic, and when Best Buy had to shut down stores because they were not considered “essential,” it could have been a death blow considering the likes of Walmart and Target were able to stay open and Amazon was already a via competitor online.
However, their API-first architecture allowed them to pivot to a 100% contactless curbside pick-up model in a matter weeks. This enabled them to keep 80% of their forecast revenue without having a single customer set foot in their stores. This made Best Buy one of the many pandemic success stories, as they were able to grow revenue by 3%+, which is something only the “essential” big box and grocery chains were able to do. There are tons of stories about Best Buy’s success online, this Forbes article offers a good overview of what they did from a business side perspective, but it would not have been possible to move quickly if they hadn’t digitally transformed to an API-first architecture back in 2011-2014.
Our comprehensive guide to getting started with headless commerce will teach you more about the architecture, how to work with the front-end of your choice, and how to choose a platform your needs.
Companies that have layers upon layers of legacy infrastructure will need to build a legacy modernization plan that focuses on deconstructing monolithic architectures and creating more service-based and reusable components. The outcome of this approach will help to reduce costs, create new re-usable components that were previously hardwired and ultimately improved efficiency of the business. For eCommerce specifically, modernizing the architecture can enable unique omnichannel experiences, by focusing on unlocking data and then using it in new ways to present content, pricing, and customer support experiences across mobile, Web, IoT or instore. Today's digital economy makes multi-channel the expected norm of buyers, even more so after the pandemic.
Many buyers that come to Elastic Path describe their eCommerce project as a Digital Transformation. In the context of APIs that means investing in an eCommerce platform that can integrate with existing and ever-expanding technology ecosystems.
Digital Transformation has led to the rise of Headless Commerce architectures, where APIs are used to connect a back-end commerce platform with a variety of front-end experiences such as CMS, IoT, Mobile, etc. That created a path to multi-channel, but the original headless eCommerce solutions were still a back-end monolith that made it very labor intensive to optimize/add new experiences on the various and in many ways disconnected front ends. Business logic was engineered in siloes with very few reusable components. The transformation is now moving to a fully composable, microservices-based architecture. Elastic Path Commerce Cloud is an example of this new approach, which is now leading to faster time to market of multi-channel, multi-brand, multi-geo and B2B scenarios where each customer in B2B or B2C, becomes a "segment of one" when it comes to catalogs, pricing, and product availability.
In B2C, retailers are well under way to modernizing their customer experiences by integrating online and offline channels – for example BOPIS is becoming almost common place even in niche retail markets. Buying experience are becoming more interactive and engaging and physical inventory can be kept in the warehouse and shipped directly to you or called up on demand whether you are instore, in your car or on the couch. Knowing things will continue to evolve and buyer expectations will be more and more digital driven, future proofing with a composable, API-first architecture is more and more critical to explore now than ever.
In B2B, digital transformation is just getting started as companies are looking for ways to blend online sales with the complexities of account management that won’t cannibalizing top revenue generating channels like resellers and distributors. B2B account management can be a mix of managing repeatable transactions and transactions that have custom pricing and contracts, bespoke onboarding, unique delivery logistics, personalized service, and support. The big opportunity in B2B eCommerce however is the buyer does not want to meet with the account team just re-order the same parts, consumables or schedule a service call. They also want to self-service how they explore new product offerings, and don’t always want to take a meeting to explore and purchase new offerings, especially when there is already a relationship in place. Add to this the fact that “the buyer” is not an individual with a single persona, but rather a complex team of buyers across multiple personas and decision-making influence.
Companies looking to implement a more MVP approach to B2B eCommerce, we will want to ensure it adds value to the relationship while also optimizing the internal account team support of the account. So digital transformation is not just about using an API-first architecture to enable a headless front end (buyer experience), it is equally important to integrate reusable assets on the back end like ERP, CRM, OMS, etc., making sure the customer and account team have clear single version of the truth across every transaction.
An example in B2B that I was personally introduced to in my consulting days was Caterpillar. They had a technology that could monitor every machine’s performance in the field, and they the machine would “phone home” a status back to a central database at both CAT HQ that dealers could access. The idea for enabling eCommerce was to connect this data with their parts store and dealer services that can fulfill an order before the machine breaks down. This turned the construction vehicle into an IoT digital experience, allowing customers to participate in a program where parts and service were ordered automatically and delivered to the machine in the field based its location. This not only adds frictionless ecommerce to their business model – value to the customer, but it also enabled more control of machines warranties and service histories so that their dealer account teams can use the data to upsell and cross-sell new machines. Learn more about what CAT did here.
Companies that are new to eCommerce or are putting together a business model with eCommerce as the core of their revenue strategy will want to consider investing in digital native solution providers to create their own digital native architecture. This will enable them to future proof their business and create endless market leading experiences as they grow in their market. This type of investment also requires some technical skill, but as more Pre-Composed Solutions™, business-ready pre-integrated commerce applications, become available cross an ecosystem of digital native tools and partners – we think even the smallest eCommerce investments will move down the API-first path vs. SaaS monoliths with cookie cutter templates.
In addition to starting your eCommerce with a digital native approach, we are seeing more and more companies that invested in monolithic “starter” eCommerce platforms looking to re-platform right around the $2-$5M annual revenue mark so that they don’t get locked into a platform that ultimately hingers rapid growth of the business through agility.
If you are evaluating a solution like Elastic Path Commerce Cloud, then you are adding a Partner API Business Model to your architecture.
Platforms like ours enable "Ecosystem" external API business models, where we make APIs available to our rapidly growing partner network to develop new solutions that can be resold across many customers. This the basis for our Pre-Composed Solutions™ and Accelerators that we in turn resell to our end customers in collaboration with the partners that developed the solution. Most major application cloud provides have a version of this, for example most folks are familiar with is the AppExchange on Salesforce. Customers typically would not manage these connectors as they come pre-built with the partner solution and are supported under a Composable Commerce XA™ services model.
If you are connecting your goods or services to external sites for referrals that drive traffic to your site, you likely have developed an Affiliate API business model. Some of these API models go beyond linking, tracking and revenue share contracts – Air Malta, for example, opened its booking system via a web services affiliate API to enable partner carriers to book flights directly with Air Mala without the customer having to leave the partner site where they started.
Since many modern eCommerce architectures require a mix of legacy and digital native solutions, there is likely a need to purchase a custom developed APIs to bring these systems together. Many of Elastic Path’s business partners provide these types of options so that major back-end systems like ERPs don’t have to be replaced to transform into reusable components of an API-first, headless commerce architecture.
One strength of Elastic Path is working in regulated industries like Telecommunications and Healthcare. As a result, many of our customers need to consider how they include API Business Models into their eCommerce workflows to ensure they meet government and industry-based rules and regulations when it comes to things like PII (personal identifiable information) data and financial transactions. An example of an industry standard API Business Model we see every day is SWIFT. This allows for all banks to engage with commerce using a common data structure, working and security considerations. This model is also evolving into a “pay later” option that allows for online transactions to be essentially financed on the fly, so the vendor gets paid in full and the customer gets options to select a bank backed finance program in real time while checking out.
Many eCommerce tools that leverage an API-first architecture operate their business model using a productized approach. Essentially, they offer more functionality and access to API services based on the tier of product you are on or consumption of the APIs you use.
Contentful, a CMS Elastic Path partners with is a great example of an Upsell API Business Model. They offer a developer kit to get started with their solution and you can start connecting back-end services using their RESTful APIs, however if you need more enterprise horsepower you can upgrade to their enterprise plan to get access to the GraphQl Content API. Salesforce CRM is another example of a upsell API. The only way to get access to their suite of APIs is to be on the Enterprise or Unlimited plan, which increases the cost per user by 6-12x compared to their lowest tier of service, Essentials.
Every seller’s eCommerce architecture has at least one (but likely several) payment providers integrated with it. The payment providers use their APIs to connect and process payments and charge a per transaction fee. They monetize by charging for each call and/or a percentage of each transaction value. Such APIs are often integrated into scenarios like eCommerce stores or point-of-sale devices. eCommerce platform providers tend to offer pre-developed solutions that become virtual plug and play, but if your eCommerce platform is API-first, with some straightforward development you can connect to just about any provider in world. With currency like BitCoin and more online banking options – this is become a competitive differentiator as buyers have preferences for how they want to pay digitally.
Marketing APIs is when the API is a value-add component to how a company markets and sells its product or service using an open and accessible API model. Elastic Path Commerce Cloud provides this type of API business model to is end customers so that they can connect our eCommerce solution with legacy and new digitally native applications and services. This is known as a Packaged API business model. As the customer, you are paying Elastic Path a license fee to gain access to the platform features and APIs that can be used to connect with both internal (behind your firewall, like an ERP, CRM or Relational Database) and external data sources/applications (payment providers, tax services, etc.). Elastic Path does not charge per API call, but instead we enable our customers to increase revenue across omni-channel experiences for which our license fee is aligned on either a revenue or transaction-based metric.
You can learn more about our pricing model on Elasticpath.com.
Hopefully this article has helped bring some context around APIs business models and eCommerce use cases they enable. The exciting journey we are all on with a API-first, composable commerce architecture is that we can create almost infinite buying experiences and integrate that in any existing back-end business process or external service. We look forward to taking this journey with you!