Headless e-commerce requires the API layer to carry the business rules

Headless e-commerce becomes relevant when the same range has to support a content website, a product website, a customer portal and a reseller portal, and each channel has its own release schedule. Prices and stock need to match across every interface. So do customer login and order status. At the same time, marketing wants to adjust navigation and campaign pages without waiting for the next release of the business system.

The question is about separating the presentation layer from the core commerce functions. Product data, prices, stock, orders and customer login stay in the core. The interface can then be developed and published on its own. It is an orchestration of the business system, PIM, CMS and e-commerce.

According to Statistics Sweden, 36.7 percent of Swedish companies with at least ten employees sold through e-commerce in 2024, often across several channels at once.

Why headless e-commerce is becoming a question for your business now

When sales grow across several digital channels, a shared release schedule can become a bottleneck. The product website, customer portal and reseller portal don’t need to change at the same pace. The question is whether the business gains from decoupling the interfaces, or whether an integrated platform still gives lower cost and risk.

Headless becomes relevant when different channels need their own buying journeys but should draw on the same business data. A building supplies retailer may need to show stock and delivery options early in the purchase. In another product category, price and availability may matter more. The interfaces differ, while the business’s need for correct information stays the same.

Count the channels that need their own releases before you choose technology. Then assess the cost of development, integrations and ongoing management over three to five years. If you have one web shop and a shared release schedule, an integrated platform may be simpler to run. A composable stack of your own fits better when the channels’ needs and pace of development genuinely differ, and you can take responsibility for more system connections and more ongoing coordination.

How frontend and backend work together through the API layer

An order can start in a web shop, a customer portal or a reseller interface. The API layer makes sure every interface uses the same business rules and gets the right information from e-commerce, PIM and the business system.

The frontend handles navigation, search, content and checkout. The e-commerce platform handles the cart and orders. The PIM supplies enriched product data. The business system exposes stock, prices and order status.

Two types of calls serve different needs.

Asynchronous events publish product, price and stock changes as they happen. The PIM and cache are then updated. This works for product listings, search and campaign pages, where a short delay is normally acceptable.

Synchronous calls fit when the customer needs a current answer, for example for price calculation, permission checks and order validation. A cached stock level or price should not decide whether an order is approved.

Take an order flow as an example. The customer adds a line to the cart, and the frontend asks the API for the current price and stock. The order command gets an idempotent ID, so a retry doesn’t create a duplicate. The business system acknowledges the order. If the acknowledgement doesn’t arrive, the interface needs to show a clear status while compensation logic handles the remaining case. A correlation ID makes it possible to follow the call through the services.

Read more about how the order flow connects to the business system in the article on e-commerce and the business system.

Track p95 API response time, sync delay, the share of successful order calls and errors per integration. These metrics show where the flow loses time or reliability, whatever frontend framework you use.

The benefits that hold up under scrutiny

When a campaign page needs changing in the same week the business system is updated, a decoupled frontend can give teams different release cadences. You can adjust navigation, search and content without touching the order engine. The gain shows mainly when responsibility for channels and the business system is clearly divided.

The same product, price and order logic can serve a web shop, a customer portal and a reseller channel. That reduces the risk of conflicting business rules, but it requires the systems to actually share data and responsibility.

The benefits depend on how you work. Independent releases require versioned API contracts, so the interface keeps working when the platform changes. Shared domain logic requires common handling of customer identity and permissions. Faster channel changes also require clear boundaries for what is fetched live and what can be updated afterwards.

Capacity needs to be assessed against your own traffic peaks, such as campaigns, seasons and price changes that hit every channel at once.

Campaigns can put load on product listings, stock status, prices, carts and payments at the same time. Caching helps the presentation layer respond quickly, but current prices and stock still have to be checked where the order is processed. Load testing, monitoring and fallback routines need to be part of deployment.

Track Core Web Vitals, the API error rate, cache hit rate, the time from product change to publication and the time from order to acknowledgement in the business system. These metrics show whether the architecture works for the business, whatever frontend framework you use.

The challenges decoupling brings

An order can sit without acknowledgement from the business system while the customer sees a confirmation in the web shop. Gaps like that become more common when more components are each responsible for part of the flow. The question is how many business processes you need to build, test and maintain between the systems.

Correct prices, order status and stock information matter more for every step that passes through several systems. An error in one component can spread if the systems lack clear rules for handling outages.

Troubleshooting requires visibility across the frontend, cache, search, API and business system. Without central logging and tracing, it becomes hard to find where an error occurs.

Ongoing management requires broad skills. The team needs to understand the API contracts, the commerce rules and the interface. That affects staffing and how quickly you can fix errors.

Incident responsibility has to be clear. If the business system doesn’t acknowledge an order, the customer needs to see the order’s status. The system also has to prevent double registration and define how the order is resumed. Otherwise the customer may think the purchase is complete while the business has no handled order.

So decide who responds to alerts outside office hours and who has the mandate to fix the error. If the answer requires a new quote every time, the ongoing risk becomes part of the architecture’s cost.

When headless is the right choice and when an integrated platform fits better

Choose headless when several interfaces need to be developed and released separately but still share business logic. Choose an integrated platform when requirements are more stable and you want to reduce the number of components to maintain. Compare the options over three to five years, including development, operations, integrations and incident handling. The same trade-off is covered in the article on composable commerce.

Headless fits when several channels need separate releases. You then need your own contracts with the business system and PIM, responsibility for monitoring and fallback, and you handle rendering and SEO yourselves. It requires broader skills across frontend, APIs and integrations.

An integrated platform fits when you have one or a few channels and can use ready-made connections with a defined scope. There are fewer parts to monitor, publishing is handled in the platform and running costs can be lower when requirements are stable.

Glanser delivers digital solutions in a product-driven way, with pre-built, tested functions and integrations at a fixed price. The work can include standard functions shared by everyone, adapted standard functions developed and tested for your needs, or customer-unique functions with a clear scope. Read more about how to choose an e-commerce platform.

The approach requires a product owner, a clear data source per field and someone responsible for incidents. If you can’t staff those roles, you should start with a smaller scope.

ERP, PIM and customer portals in the same architecture

The business system normally owns stock, prices and order status, while the PIM is responsible for enriched product information. Decide ownership per field before you build the flows. If a technical specification changes in the PIM, the same value should reach both the product website and the customer portal through the shared data model.

Prices, stock and product data come from the same source, while interfaces are adapted to the user’s role. A buyer, a reseller and an internal salesperson can therefore see different views of the same product and customer logic.

In the customer portal, customers can download invoices, track deliveries, manage users, reorder from their order history and see customer-specific contract prices. They get answers to routine questions without calling support. The sales team gets more time for advice and more complex deals.

Write the responsibility matrix before you design the interface. A field without an owner can lead to contradictory information across channels.

Measure how long a changed technical specification takes to reach the product website and the portal. If the value differs between channels, you need to review the data flow and field ownership. More on structure and responsibility for product information is in PIM for e-commerce.

For groups with several brands, a shared model can reduce duplicate work and keep data flows consistent as new markets or portals are added. That requires the companies to agree on fields, rules and responsibilities. If each business needs entirely its own data rules, separate solutions may fit better.

Three questions to ask the supplier

Ask these questions in your next meeting, and ask for answers in operational terms.

Who owns stock, price, enriched product copy and order status in the responsibility matrix between the business system, PIM and e-commerce? An answer that points to people and fields shows the model has been drawn. An answer that says it will be sorted out in the integration means you’ll discover ownership during an incident.

How is compatibility maintained when the platform and business system are upgraded, and who fixes a broken contract without a new quote? The answer shows whether you’re buying a project or responsibility over time. Version tracking, tested functions and bug fixing belong in the agreement.

What is included in ongoing management after go-live, and which metrics are reported each month? Ask for the API error rate, sync delay and time from order to acknowledgement. An evasive answer means responsibility stays with you whenever something falls between the services.

Next steps for your assessment

Start with the question that affects your day-to-day work most: does the existing solution need stabilising, or does the division of responsibility between ERP, PIM, CMS and e-commerce need to change? If the platform is unstable, a technical review can show what can be kept and what should be replaced.

Then weigh the options over three to five years. A composable stack of your own can give more freedom, but it requires you to take responsibility for more integrations and ongoing management. A productised, ERP-integrated solution can reduce that risk when your needs fit within proven functions.

In a 72-hour analysis, you get a structured picture of your current functions and integrations, along with concrete next steps.