A comprehensive technical guide to headless commerce

Have you come across the term “headless commerce?” It’s being used more and more, cited as the underlying reason for new shifts in commerce technology. I kept hearing it in meetings, and I wasn’t sure if any of us really understood what it meant. I wanted to grasp the concept better and decided to compile all of the information around headless commerce for marketers and technical teams, including what it is, where it came from, and why. 

eCommerce hasn’t been around all that long – the web appeared in 1990, with eBay and Amazon launching in 1995. Since then, software development has evolved from monolithic and layered architectures to web services and microservices. As eCommerce technology stacks have become more sophisticated to incorporate personalization and support new digital touchpoints, eCommerce software is now following the same path. It is moving from monolithic platforms towards services and APIs, which headless commerce is taking advantage of. 

Headless commerce definition

So what does headless commerce mean? 

The simplest definition of headless commerce is that it is a commerce platform without a frontend. Meaning, the frontend, which refers to the user’s web browser application, is separated from the back end platform running on a server somewhere. The interesting questions though, have to do with how it all works, why it’s a good idea, and the effect on teams buying, managing, and using the software. 

First, though, some terminology. 

Terminology associated with headless commerce

Perhaps all industries are the same, but the more time spent in eCommerce, the more three-letter acronyms (TLAs) and jargon you encounter. To add to the confusion, the same words mean different things to different people. 

“Because no endeavor is respectable these days without a TLA.” – Dijkstra, 1988

To help clarify, here are some that often come up regarding headless commerce:

• Content Management System (CMS) – Software used to create and store articles, images, videos, or any other digital content. 

• eCommerce platform – Software that businesses leverage to sell products and services online. 

• Personalization engine or platform – Software that provides tailored messaging, content, and recommendations across digital channels.

• Digital experience platform (DXP) – A lower-level architecture component that combines services to create connected, personalized customer experiences

• Monolithic software – Applications where all of the code for the user interface and data access are combined. 

• Frontend – The user interface. In this context, what people use to buy your products, e.g., your website. 

• Backend – The system that processes and stores data, usually sat on a server somewhere.

• Application Programming Interface (API) – A connection allowing applications to interact with one another and set of functions that can be called to access data or trigger actions, e.g., return product data or make a purchase. 

• RESTful – An architecture for web services such as APIs which permits requests through uniform resource identifiers (URIs) to retrieve all of the information necessary without storing client state on the server.

• Web services – Web servers that respond to requests for the completion of a domain-specific specific task. 

• Microservice architecture – A structural style that arranges applications as a collection of loosely coupled services.

• Loose coupling – Where different combined services have as little dependency on each other as possible, e.g., a change in one service doesn’t require all others to be updated. 

• Presentation and application layers – Layers of the open systems interconnection (OSI) model for telecommunications. Here, presentation could include decryption of data and, application, a set of APIs. This term is often misused to describe the decoupling of frontend and backend. 

• Omnichannel – The practice of utilizing numerous channels of interaction for the creation of a consistent customer experience across web, app, email, call center, in-store, and so on. 

Headless commerce explained

As defined above, headless commerce works by separating the user interface (frontend) from the software, which does all the processing (backend). The headless commerce platform is just the backend part, with some way to connect one or more user interfaces. This connection is generally made through APIs, and because this provides a generic interface to the platform, any frontend can be built to connect to it. 

A user then interacts with a frontend running in a web browser, a mobile application, kiosk, or any other digital interface, which then, in turn, communicates with the backend. 

To demonstrate this, here is a simplified example user journey:

1. A user navigates to a product on an eCommerce website. The frontend is loaded in the user’s web browser and the product details are retrieved from the backend by API.

2. The user makes a purchase, causing the frontend to send a request to the backend making the purchase.

3. The backend does all of the processing and then responds to the frontend to tell it the purchase was successful.

By decoupling the frontend and backend, the backend can be far more generic. It is able to interact with anything that is willing to send the correct API requests. The frontend also becomes far simpler because it doesn’t have to deal with any of the processing, it is just displaying information to the user. 

Monolithic versus headless architectures

In describing how headless commerce works, some of the differences between headless and monolithic architectures have already been touched on. These advantages and disadvantages all come about because of the decoupling of the frontend and backend.

First, I’ll list the pros (mostly) and cons (limited) of the headless commerce architecture, and then explain why these come about. 

• Development is simpler
• One backend can power several frontends
• Integration with other systems is easier and more flexible
• More technical knowledge is required

Development

A system based on a headless commerce architecture makes development easier because changes can be made to the front and backend independently. In a monolithic system, any change to the way information is displayed to the user requires knowledge of the entire system – an understanding of how that information is both accessed and processed. For any change which is made to one system could break the other. It is also more likely that a change could invalidate software warranties and cause issues with future upgrades. 

In a headless commerce system, a front-end developer can make any change they like while only needing to understand the interface to the backend – the APIs – and back-end developers can enable new functionality by supporting new APIs. Due to the more simple nature of making changes, development can be quicker and more agile. 

ICYMI, Dynamic Yield is offering a free 14-day exPerience APIs trial. Simply sign-up for access to a sandbox environment and start playing. 

This separation of front and backend also allows developers to specialize. For smaller teams, this means new functionality can be developed more quickly. In the case of larger teams, it is easier to find qualified developers, and, in general, these individuals can more intimately understand their areas of expertise. 

This decoupling also enables completely different teams to manage the various systems. Or systems even being managed by different companies – a new frontend could be licensed as SaaS, for example. 

Multiple frontends

Because the headless commerce system only has to provide an interface (through APIs) to the frontend, this adds flexibility. Initially, the only user touchpoint connected to the back end might be a website, but with headless, a mobile application could be connected, PWAs, kiosks, smartwatches, voice interfaces, and so on. 

Only one system has to process information with a decoupled headless commerce platform, so there is less development effort required to support all touchpoints, and consistency can be maintained across them. There is also an element of “future-proofing.” For example, Web technologies move very quickly – when something new comes along, it can just be plugged into the existing backend. 

Integrations

Following the theme of flexibility, having this generic interface through APIs allows for easier systems integration, both internal and external. For instance, a new payment gateway can be added by making calls to a new API. 

This flexibility also extends to changing integrations, reducing vendor lock-in, and creating greater opportunities to trial and test new services. Want to determine if a new search provider is stronger than your current vendor? Now, you can experiment more readily. 

The result is a more interesting toolset. In the two examples above, a testing and personalization provider can be used to optimize the search and payment systems or even tailor the experience. Perhaps more loyal customers are offered more payment options. Additionally, conversion rate may be improved by offering specific segments of customers different payment methods than others. The number of eCommerce tools available is growing exponentially, so being able to test and integrate these tools quickly can have a major impact on business results. 

Technical Knowledge

One requirement to take advantage of the possibilities listed above is that a team has the skills to implement these changes. There are notable differences between implementing one system that takes care of everything versus assembling a set of interconnected ones. The current trend in eCommerce is to partner with “best-of-breed” solutions, but this isn’t possible without additional skills, and if it is a requirement, then headless commerce solutions lessen the pain. 

The team will need to involve similar members as in any tech-focused eCommerce company – front-end developers, back-end developers, architects, project managers, etc. – only now there must be close alignment with the marketing team. 

5 things to consider when choosing a headless platform

1. Is a frontend packaged with it?

Some headless commerce platforms come with both the back and front end, which will be seen as an advantage by some, and a disadvantage by others. It depends on your requirements – if you have a team of developers who want to build a custom site and app, you may not want a ready-made frontend website. However, even if both bits come together, you still have all of the advantages detailed above, including the future flexibility to change frontends, add new digital channels, integrations, and develop your eCommerce stack more easily. 

2. Does it have APIs which cover your required integrations?

If you already have requirements for integrations with existing or planned tools, then these need to be validated. This should be understood by the team who will need to build the integrations as there’s a big difference between an email service provider (ESP) having an available API integration and knowing that the API will work with your chosen ESP. 

3. Are its APIs generic enough to support future requirements?

We don’t know what the future will hold, but it is almost certain that there will be significant changes. In eCommerce, we may not be able to plan beyond five to ten years, but the platform chosen needs to keep up with the more immediate needs. If bringing kiosks into the store is on your roadmap, then this support can be validated. For everything else that might happen, it is worth comparing how generic the APIs provided are – a well-designed interface should allow integration with a wide variety of tools in a variety of ways. 

4. Can your team understand how it works?

Because there is more technical involvement to get the most out of headless commerce, it is important that development teams have the required skills, access to the relevant code, and also that they can use the platform as efficiently as possible. This includes how well-designed the interfaces are, how good it’s documentation is, and what support and training are provided. Having your team review any available documentation would be a good place to start. 

As well as the technical teams, business teams must be able to manage the solution: marketers to create content and merchandisers to serve the right products, all through the new system. As well as asking similar questions as above, it is important to consider what interface is provided for ongoing management, or if this will need to be developed. 

5. Is your company set up to take advantage?

All of the benefits of headless commerce listed above are of little value if the business can’t take advantage of them. A few questions to ask when determining if a company is ready:

• Are the advantages relevant to my business, size, products, services, and development phase?
• Does my company’s strategy align with these advantages? For example, is there a need to connect online, offline, or other touchpoints? Will the ability to flexibly design these touchpoints provide a unique value proposition?
• Are my teams prepared? Do they have the necessary expertise, is there enough bandwidth to support a new project? This applies especially to technical teams, but everyone else needs to be on board too. 

Where do personalization and testing fit in?

Marketers are interested in delivering personalized, optimized, and synchronized experiences, so how do we combine these systems? I’ve already answered this to some extent when discussing integrations, but because everything in a headless commerce architecture has APIs, accomplishing these goals is far more attainable. 

Both the headless commerce and personalization platform provide APIs, so if you want to test search providers, you can just run an A/B test between the two API endpoints. However, for such tests, it is more necessary to involve technical team members. Someone needs to understand the search interface and write the code to direct a portion of users to one search provider and another batch of users to the other. 

It’s important to note that not all tests need to be run using APIs; they can be combined with client-side testing. With the headless commerce platform, you have the opportunity to build more interesting API-based use cases and take advantage of client-side’s ease of use to enable the marketing and business teams to iterate more quickly without heavy reliance on tech teams. 

The APIs from the headless commerce platform are combined with those from the testing/personalization platform to build an experience. There are different approaches which can be taken, depending on the intricacies of each tool, but at a basic level, it follows this pattern:

1. Multiple variations are created in the headless commerce platform – this could be something simple, like a banner on the homepage, or something more systemic, such as the search provider.

Let’s say three variations are created: A, B, and C.

2. These variations are then referenced as variations in the personalization platform, allowing the configuration of testing and targeting. For example, variations A and B are configured to be tested for all users, apart from those in the south of the country., who are to be shown variation C. 

The personalization platform doesn’t need to understand what the variations are – it just needs to know which variation should be shown to each user and measure what happens when the users interact with them. 

3. When a personalized experience is to be shown to a user, the request the frontend makes is intercepted and made to the personalization API. The personalization API then returns a reference to the headless commerce platform’s variation, which is retrieved from the headless commerce platform and ultimately returned to the frontend.

4. The frontend shows the returned variation to the user.

5. Events are sent to the personalization platform to measure interactions with experiences and KPIs such as conversions, add-to-carts, and purchases.

A true competitive advantage, when ready

Headless eCommerce solutions bring many benefits over traditional platforms due to decoupling the frontend and backend. Although a seemingly simple architectural change, the flexibility of developing on top of a headless commerce platform translates into greater experimentation with new features and integrations. And, more importantly, quickly and easily. As long as the company is set up to implement these changes, adopting a headless approach can be a true competitive differentiator.

Check out Dynamic Yield’s developer hub for information on how an A/B testing and experience optimization platform can be connected to a headless commerce platform via APIs, and then give them a test run with our free 14-day exPerience APIs trial.