A Base Layer API Provides the Structure and Flexibility to Compete

Explore how a base layer API serves as a critical solution in modern ecommerce, enabling seamless integrations and providing the foundation necessary for agility and growth amidst rapid market changes.

The ecommerce industry is in a state of rapid change, and business leaders are always looking for ways to add flexibility and speed while supporting the systems that have sustained them for so long. 

An IDC report found, for example, that 67% of business leaders are at least considering changing their commerce platform in the next three years. However, 61% said the process of implementing new tech will be challenging. 

These problems tend to feed on each other: The desire to swap platforms or change systems can be compelling if a previous system isn’t flexible enough, while that lack of flexibility can make it difficult to implement new technologies. 

The key ingredient missing in many of these discussions is a base layer API—a foundation that provides trustworthy support while enabling flexibility and speed as new features are added, iterated, or integrated. As competition intensifies, the balance a base layer API provides is proving a vital component for lasting success. 

What is a base layer API, and why is it important?

To start: An API, or application programming interface, is a mechanism that allows applications to “talk” to each other. With an API integrating them, different software components can share data and access functionalities without accessing the internal details of the other components’ systems. 

A base layer API is a particular type of API that acts as a central hub that connects all the different applications and services that a business depends on. Think of it as the common shared language that allows all your systems to communicate with each other without issue, or as a currency-conversion point that allows different countries with different currencies to import, export, and trade. 

As the ecommerce technology market fragments, the lack of a base layer API increasingly makes every new integration a pain point. Without a base layer, companies often feel like they’re reinventing the wheel whenever they want to add something new. 

The downfall of a fragmented system

A decade ago, many enterprises looked at off-the-shelf platform options, determined they were inadequate, and built custom platforms. Now, many more options have emerged—ranging from out-of-the-box monolithic solutions to completely composable assemblages of tools. As a result, many businesses are spread across different solutions and strategies, resulting in fragmented systems. 

You can characterize a fragmented system by three primary aspects:

• Closed partner networks: With no or few open APIs, integrating new services becomes difficult, time-intensive, and onerous. 
• Lack of flexibility and customization: With inflexible APIs, it can be time-consuming to make even minor changes, which can result in tech debt over time.
• Inability to integrate new technologies: Without flexible, modern APIs, it can be impossible to integrate with new and emerging technologies, such as the cloud, new social media platforms, and app stores.

Companies don’t seek to build fragmented systems, of course. Typically,t companies either build monoliths, in which all the components are tightly interwoven in a way that limits additions to the system, or they build custom platforms and have to add dependencies over time until the system is effectively fragmented. 

Without a base layer API, many challenges can result, including: 

• Higher total cost of ownership (TCO): Fragmented systems require a dedicated development team, which leads to high maintenance costs and high opportunity costs as companies reallocate development resources from feature work to maintenance work. 
• Reduced agility: Over time, fragmented systems make it harder and harder to meet the market quickly. When it’s difficult to add new and emerging technologies to a system, the system and the company can lag far behind the rapidly evolving market. 
• Maintenance headaches: With fragmented systems, integrating a new app requires building a specific link between each new app and all the other services. Over time, this leads to a tangled web of connections. Eventually, each update feels like removing a single Jenga brick from a rickety tower of other bricks. 

One merchant, for example, was using a headless platform and ended up with multitudes of connections. Each component needed to be connected to many other components, and changing any of those components proved difficult. And because they worked with an agency to service the API layer, they endured a bill for every single API call. Four years later, as the merchant scaled, it amounted to a 400% increase in TCO. 

Why brands choose headless

Headless architectures can solve the fragmented system dilemma, but not all headless systems are the same. At a foundational level, however, headless systems offer numerous advantages, including:

• Composable architecture: Headless systems allow companies to have different systems working together flexibly. And thanks to that flexibility, companies can continuously swap new components in and out, allowing them to keep up with best-of-breed features. 
• Omnichannel: Thanks to their inherent flexibility, headless systems are agnostic about the channels companies use to reach their customers. As a result, these systems can support companies in an increasingly omnichannel world, since they’re not locked into any one channel and have the freedom to expand into new ones. 
• Flexible development workflows: Headless systems are modular, allowing companies to spend their development resources wisely. Monolithic and fragmented systems restrict modularity—either by limiting it entirely or by making it difficult. With headless systems, development teams can more easily adopt agile development workflows, develop different features in parallel, and iterate without undue cost. 

Fully composable solutions can be unnecessarily complex

Given the risks of fragmented and monolithic systems, many companies flip from one extreme to the other, shifting from overly restrictive systems to overly composable ones. 

The logic here makes sense at first glance. Composable architecture proponents tout these systems as the ideal because in theory, they allow complete flexibility. But in many contexts, too much flexibility can result in too little support and too high costs. Consider these disadvantages:

• Time to set up can be high: In a fully composable system, each component takes time to set up, and much of the system can remain nonfunctional until every piece is in place.
• Development costs: A fully composable system requires a team to work with that composability, meaning implementation can take a long time, and development costs can remain stubbornly high. 
• Complex architecture: Fully composable systems can become very complex, leading to a different form of fragmentation over time as development teams struggle to keep up.
• Increased costs: Fully composable systems require a lot of maintenance, allocating expensive development resources to keeping the lights on instead of net new feature work.
• Inflexibility: Ironically, despite these systems touting flexibility, composable systems can end up inflexible over a long period of time. Eventually, it becomes difficult to add new technologies or switch to different platforms. 

The central source of these problems is known as extract, transform, load (ETL). ETL is a fundamental process for any system that moves and combines data. In a typical system, companies use ETL to extract data from a source, transform the data into a format that can be analyzed, and load the data into a new system, such as a data warehouse, data lake, or a new database. 

The trouble with ETL is that, in an already fragmented system, companies can end up with further fragmented systems as they build customized middleware to connect different data sources and APIs. If one API has one “full name” field and another app has “first name” and “last name” fields, for example, you’d need to build middleware between the two to pull the “full name” field (extract) and break it into two fields (transform) so the next data source can ingest it correctly (load). 

This is a simple example, but the more this process is repeated across more complex situations, the more fragmented the entire system becomes. 

If a company uses a third-party promotion solution that works well within a custom DTC system, for example, this dynamic could make it hard to add new channels. If the company wanted to add a B2B feature, they’d have to create a large, custom piece of middleware to match the new complexities of B2B with the DTC discounting feature. Think company, location, volume pricing, tier pricing, and more.

After building such a complex piece of middleware, you’d find out the middleware is actually your B2B discount engine. Unfortunately, this engine is also now completely dependent on your original DTC promotion solution. This means that if the company wants to change out the third-party DTC promotion solution, they now need to integrate it into this custom B2B discounting middleware, which will increase the scope of the project times 10. 

Build the way you want on Shopify

With a base layer API and the support of Oxygen and Hydrogen, Shopify allows you to build how you want. Stores can build headless storefronts with Hydrogen’s React-based framework, and with Oxygen, companies can deploy those storefronts for free and scale them with the support of the world’s largest commerce ecosystem. 

These tools offer you a variety of options, including:

• No code: Use the Shopify theme editor with a broad ecosystem of apps to build an online store.
• Low code: Use the Shopify theme editor and theme code to build a custom store with little technical investment. 
• Custom code: Use a merchant-managed front end and the Shopify storefront API to build a totally unique storefront.

Shopify gives you the foundation of your ecommerce system via Oxygen and Hydrogen and provides as much flexibility as you want to build the rest of the store. Third-party tools are easy to integrate, and a rich ecosystem of native apps gives you even more options. 

And if you’re migrating from a custom or legacy system, you don’t have to worry about building the burdensome middleware we warned you about here. Shopify provides open APIs you can use to build your team’s infrastructure exactly as needed.

Build higher and reach further with a base layer API

A base layer API is a critical component of modern tech stacks because it allows companies to get the best of both worlds—the reliability of solid infrastructure and the flexibility to iterate—while giving them the ability to swap components in and out over time. By embracing a headless approach, with tools like Shopify's Oxygen and Hydrogen, companies can future-proof their businesses by making agility a founding principle.