What Shopware headless means technically, which frontend options are still maintained in 2026 (Shopware Frontends, Next.js, no longer Shopware PWA), what a custom frontend costs, and when the Storefront is enough.
Shopware 6 is headless-ready out of the box. The Store API delivers products, cart, checkout, and customer account as JSON, a machine-readable format, and the included Storefront uses the same routes internally. A custom frontend is therefore an option, not a requirement.
Headless pays off in a few clearly defined cases: multiple channels from one backend, brands with a very high share of content, apps and portals, or a development team that already works with Vue or React.
Budget at least €40,000 for the frontend, and after that, two systems in ongoing operation. For most merchants well into seven-figure revenue, the Shopware Storefront with a custom theme is the more cost-effective choice.
A custom frontend promises design freedom and speed, but it costs several times as much as a theme and doubles your operations. This article is for CEOs and ecommerce managers facing a platform or relaunch decision, as well as merchants planning an app, a portal, or additional brand sites alongside their online store.
After reading it, you’ll be able to decide whether Storefront, hybrid, or headless fits your store, know which frontend options are maintained in 2026, and realistically plan budget, team, and project timeline.
Before founding solution25, we ran our own online store and grew it to more than 500 orders per day. Since 2017, we’ve been delivering Shopware projects, with the classic Storefront as well as decoupled frontends based on the Store API. Costs and team requirements are based on experience from our projects. All prices as of October 2026, excluding VAT.
Three terms often get mixed up around Shopware headless. But they describe different things, and the distinction later determines budget and team.
“Headless” refers to a system without a tightly coupled presentation layer. So a headless store isn’t a store without an interface, but one whose interface is interchangeable.
Shopware itself calls the core of Shopware 6 the “headless core” and equates headless and composable commerce in its knowledge base. For planning, it’s worth separating them: composable means more systems, more contracts, and more integrations.
Shopware 6 provides two APIs that serve different purposes in a headless project. We explain the differences, including compared to GraphQL, in detail in GraphQL and REST APIs in Shopware.
| API | Purpose | Access | Typical users |
|---|---|---|---|
| Store API | Everything a customer does in the store: products, categories, search, cart, checkout, customer account, Shopping Experiences, SEO URLs | Public per sales channel (header sw-access-key), session via the header sw-context-token | Headless frontends, apps, terminals |
| Admin API | Managing all data: creating products, retrieving orders, customers, media, configuration | OAuth access via integrations or users, path /api | ERP, PIM, middleware, custom tools |
The Store API lives under the path /store-api and is tailored to frontends: it only returns data intended for customers and works for guests as well as logged-in customers. Every call carries the sales channel’s access key in the sw-access-key header.
The session runs via the sw-context-token header. It keeps cart, login, language, currency, and payment method together without the server needing a classic session. How this works in detail is covered in our glossary entry on the context token.
The most important routes show how complete the API is: POST /store-api/product for listings and search, POST /store-api/checkout/cart/line-item for the cart, POST /store-api/account/login for customers, POST /store-api/checkout/order for the order. SEO URLs and CMS pages also come from the Store API, so a headless frontend can use the same paths as the Storefront.
One detail that defuses many debates: the included Twig Storefront internally calls the same Store API routes that a headless frontend uses from the outside. Shopware explicitly describes it this way in its architecture documentation. Technically, the Storefront is therefore already a consumer of the API, just in PHP and on the same server.
So if you go headless, you don’t get a different data foundation or different features, but a different presentation layer with a different stack, different hosting, and a different team.
In the Administration, you create a sales channel of type “Headless” for a custom frontend, with its own access key, domains, languages, currencies, and payment methods. That way, the online store, app, and B2B portal run in parallel on one backend, with separate product ranges and prices if you want.
The question of what to build the frontend with has been settled over the last three years. Some options from older articles have been discontinued.
| Option | Stack | Maintained by | Status October 2026 |
|---|---|---|---|
| Shopware Frontends (Composable Frontends) | Vue 3, Nuxt 4, TypeScript | Shopware, MIT license | Official solution, Vue Starter Template as a production-ready base |
| Next.js Shopware Starter | React, Next.js App Router, Tailwind | Shopware Labs, template on Vercel | Reference project without built-in checkout |
| Custom build with @shopware/api-client | Any JavaScript framework, including Astro, Svelte, or Angular | Shopware (package), project (frontend) | Typed client, types from the OpenAPI schema of your own store |
| Shopware PWA (with Vue Storefront) | Vue 2, Nuxt 2 | Nobody anymore | Repository archived since October 31, 2024, Alokai doesn’t list Shopware as an integration |
Shopware Frontends, called Composable Frontends in marketing, is Shopware’s own framework for headless storefronts. It consists of several npm packages: @shopware/api-client (framework-agnostic), @shopware/helpers, @shopware/composables with around 60 Vue composables like useCart, useUser, or useListing, the Nuxt module, and the cms-base-layer package, which renders Shopping Experiences from the Shopware CMS.
As a starting point, Shopware recommends the Vue Starter Template on Nuxt 4 with server-side rendering, multi-language support, and generated TypeScript types. It intentionally doesn’t include a ready-made store interface: the project assembles navigation, product pages, cart, checkout, and customer account from the composables itself.
Important for teams that started in 2023 or 2024: according to the documentation, the former Demo Store Template has been discontinued and isn’t intended for production use. There’s also an Astro template and an empty template without a UI package.
The prerequisites are Node.js 22 (LTS) and a Shopware 6 instance, self-hosted or as SaaS. The framework is open source under the MIT license, and on Shopware’s pricing page, headless isn’t a plan feature: the Store API and Frontends are also available with the Community Edition.
For React teams, Shopware Labs provides a Next.js Shopware Starter on Vercel: App Router, React Server Components, Server Actions, Tailwind, connected via @shopware/api-client. The starter doesn’t include a ready-made checkout. Projects either redirect to the Shopware Storefront checkout or build the checkout themselves via the Store API.
Shopware PWA, launched in 2020 together with Vue Storefront, was Shopware’s first headless approach. In December 2022, Shopware announced it would merge the project into Shopware Frontends, and on October 31, 2024, the repository was archived, pointing to Composable Frontends as the successor.
Vue Storefront is now called Alokai. Alokai’s integration list includes SAP Commerce Cloud, commercetools, Adobe Commerce, BigCommerce, Salesforce Commerce Cloud, plentysystems, and Odoo, but not Shopware. If you’re planning “Vue Storefront for Shopware” today, you’re planning with the state of things from 2022.
Existing PWA projects need a migration path to Shopware Frontends, because according to nuxt.com, Nuxt 2, the foundation of Shopware PWA, hasn’t received security fixes since June 30, 2024.
It becomes composable when content comes from a separate system. For Frontends, Shopware documents the integration of Storyblok, Strapi, and Sanity and lists Contentful, Hygraph, and Builder.io as compatible. The recommendation is that the CMS delivers editorial pages, Shopware keeps prices, inventory, and checkout, and Shopping Experiences serve as a fallback for routes the CMS doesn’t know.
The advantages are real, but they only apply if the project uses them. A headless frontend that rebuilds the same store page in a different stack has none of them.
The downsides appear less often in articles because they only become visible during the project. In our experience, six points blow up budgets.
The following figures are based on experience from agency projects, not list prices. Going headless doesn’t change the Shopware license: according to the pricing page, Community Edition €0, Rise from €600, Evolve from €2,400 per month. We’ve broken down what a Shopware project costs overall in Shopware pricing.
| Item | Storefront with custom theme | Headless frontend |
|---|---|---|
| Frontend implementation, one-time | €5,000 to €30,000 (theme) | €40,000 to €120,000, rarely less |
| Rebuilding plugin interfaces | Not needed | €10,000 to €30,000, depending on the number |
| Time to go-live | 6 to 16 weeks | 4 to 9 months |
| Hosting per month | €50 to €1,500 for the store | Store as on the left, plus €50 to €500 for the frontend |
| Maintenance and further development per month | €400 to €2,500 | €1,500 to €5,000 |
| Team in operation | A Shopware agency is enough | Frontend developers (Vue or React), Shopware developers, DevOps |
The range for the frontend comes from the mandatory scope: catalog, search, cart, checkout, customer account, CMS rendering, tracking, consent, and SEO are needed by every store, no matter how small. That’s why the price barely drops for small stores. The usual project costs for Shopware itself, integrations, and data migration come on top.
As a rule of thumb from our projects: below around €2M in annual revenue or without a second channel with its own interface, a headless frontend rarely pays for itself.
Figure: The chart shows the one-time frontend costs per option; with headless, rebuilding the plugin interfaces comes on top, which is why the approach usually only pays off with a second channel. Based on solution25 experience from agency projects, as of October 2026, excluding VAT.
The Shopware 6 Storefront is a server-side rendered application built on Twig, Bootstrap, and SCSS, with a theme system, Shopping Experiences, Rule Builder, and Flow Builder. For most merchants, it’s not the “old” option, but the one with the best ratio of features to cost.
Between the Storefront and a full build-out, there are intermediate steps that often deliver the desired effect. A brand site or magazine in Nuxt or a headless CMS, while catalog, checkout, and account stay in the Storefront. An app that places orders via the Store API alongside the online store. A configurator as a Vue component within the Storefront.
The advantage: the checkout with all payment methods, legal texts, and plugins stays as it is. The cost: the transitions between the two worlds (cart, login, tracking) have to be solved cleanly, or customers lose their cart along the way.
From projects and inquiries over the last few years, five patterns have emerged where the math works out.
The classic B2C store with a few thousand products, one language, and one channel doesn’t belong on this list. Headless doesn’t make it faster, prettier, or more profitable, just more expensive.
Foleja, a cross-border marketplace in Southeast Europe, runs on a modular Shopware 6 architecture for multiple countries, currencies, and more than 1,000 sellers. The project included native apps for iOS and Android with synchronized product, order, and notification data, meaning a second channel with its own interface, like the first pattern above.
According to the case study, the apps increased the number of daily active users and the repeat purchase rate, and overall the conversion rate was 20 to 30 percent higher. The case shows where work on APIs pays off: on a channel that wouldn’t exist without them.
| Criterion | Storefront (Twig) | Hybrid | Headless (Frontends or Next.js) |
|---|---|---|---|
| Frontend budget | €5,000 to €30,000 | €15,000 to €50,000 | From €40,000 |
| Time to go-live | 6 to 16 weeks | 2 to 5 months | 4 to 9 months |
| Team in operation | Shopware agency | Agency plus frontend developers | In-house team or agency focused on JavaScript |
| Store plugins with an interface | Work right away | Work in the Storefront, not in the decoupled part | Have to be rebuilt |
| Shopping Experiences | Complete, with preview | Complete in the Storefront | Rendering via cms-base-layer, build preview yourself |
| Second channel (app, terminal) | Possible via the Store API, separate from the online store | Yes, that’s the point | Yes, with shared components |
| Design freedom | High, within the page structure | High in the decoupled parts | No constraints |
| Risk during updates | Test theme and plugins | Both plus the transitions | Test Store API changes, maintain frontend dependencies |
| Best for | Most B2C and B2B stores | Content brands, stores with an app | Multi-channel, multi-brand, portals, JavaScript teams |
Our take: Without a second channel with its own interface, we advise against a full headless frontend and would rather put the budget into theme, hosting, and plugin cleanup. If an app, a portal, or another brand site is added, we recommend Shopware Frontends on Nuxt, because Shopware maintains the framework itself and it can render Shopping Experiences. If you want to go step by step, keep the checkout in the Storefront at first, because payment methods, legal texts, and plugins already work there.
Collect the values four weeks before the switch as a baseline, measure weekly for the first eight weeks after, and monthly from then on.
You need to make adjustments if clicks or conversion rate are below the baseline after eight weeks, the Store API responds more slowly during traffic spikes, or operating costs stay above one percent of revenue. Caching, missing redirects, or a leaner feature set usually help then.
Headless commerce, also called headless ecommerce, separates a store’s interface from the ecommerce platform. The platform delivers products, prices, cart, and orders via APIs, and the interface is developed separately and can be a website, an app, or a terminal. Shopware 6 supports this through the Store API.
Literally “without a head.” The “head” is the presentation layer, meaning what customers see. A headless system doesn’t have a tightly coupled head but can be connected to any frontend.
Shopware 6 is built API-first and therefore headless-ready, but not exclusively headless. The included Storefront internally uses the same Store API routes a custom frontend would use. You decide per sales channel whether the Storefront or a custom frontend delivers the interface.
Headless only decouples the frontend from the ecommerce platform. Composable commerce also assembles other building blocks like CMS, search, or payment from specialized services. Shopware uses both terms side by side, but for budgeting, composable is the much bigger step.
Higher implementation costs, two systems in operation, store plugins without their frontend part, rebuilding checkout, SEO, and consent, and an ongoing dependency on frontend developers. If you don’t plan for these points, you’ll pay for them later in operations.
For the frontend, we estimate €40,000 to €120,000 for implementation, rarely less, plus €10,000 to €30,000 for rebuilding plugin interfaces. In operation, add €1,500 to €5,000 per month for maintaining both systems and €50 to €500 for frontend hosting. These figures are based on experience from agency projects, not list prices.
The backend logic does, the interface doesn’t. A payment plugin still processes payments through the Store API, but its Twig template and JavaScript don’t appear in your custom frontend. Every plugin with an interface has to be rebuilt in the frontend.
Only with server-side rendering, correct canonicals, redirects, and a sitemap. Then a headless frontend ranks like any other site and benefits from fast load times. Without this work, a store loses the rankings it had with the Storefront when it switches.
Planning a custom frontend, an app, or a second channel on Shopware and want to know beforehand what it costs and whether the Storefront might be enough? Get in touch. We’ll review plugins, channels, and team, and we’ll also tell you if headless would be the more expensive solution with no added value for you.
Already running a store and wondering whether load time or design justifies a new frontend? Our free store audit shows where your current store is losing revenue and whether a headless project or optimizing the Storefront is the better path.
Learn more about how we work, our certifications, and our locations on the Shopware agency solution25 page.
Besnik Bilalli is the founder and CEO of solution25, the Shopware agency based in Bremen. Before founding the agency in 2017, he built his own online store and grew it to more than 500 orders per day. Since then, he has supported merchants with Shopware projects, from the first cost estimate to ongoing operations. He’s happy to answer questions about this article personally: Get in touch.
Responsible for content and updates: Besnik Bilalli. Last updated: October 2026. Next content review: January 2027.
