The Store API is Shopware 6’s customer-facing application programming interface (API). It provides all the data and functions an online shop needs for the shopping experience – products, categories, prices, shopping basket, customer account and checkout – and delivers them as structured JSON responses, rather than rendering them as ready-made HTML pages. This makes the Store API the technical foundation of every decoupled (“headless”) Shopware front end: it separates the actual commerce logic in the back end from the front-end presentation and makes it possible to place any custom interface in front of the Shopware back end.
Put simply, the Store API transforms a Shopware system into a pure commerce engine that delivers data on request. Anyone using Shopware’s classic, pre-installed storefront never comes into direct contact with the Store API – the storefront communicates with it internally; the retailer is unaware of this. It is only when building your own frontend – for example, using the official Shopware frontends (Vue/Nuxt), React, Next.js or a native app – that the Store API becomes the central tool. It is therefore less a single feature than the linchpin of an entire architectural decision: anyone who interfaces directly with the Store API has consciously opted against the bundled frontend and in favour of full control over the presentation.
What exactly the Store API does
The Store API is a REST API. A frontend makes HTTP requests to clearly defined endpoints and receives structured data in return. Unlike a page that the server assembles ready-made, the Store API only provides the raw data – the frontend itself decides how this data is then displayed. This is the core of the ‘composable’ or ‘headless’ concept: the backend and frontend now communicate exclusively via this interface.
Typical tasks handled via the Store API:
- Loading products and categories – listing pages, product details, variants, attributes and media.
- Search and filters – full-text search, filter aggregations and sorting for product lists.
- Manage shopping basket – Add items, change quantities, calculate discounts and delivery charges.
- Customer account – Registration, login, addresses, order history and password management.
- Checkout – Select payment and delivery methods, place and confirm the order.
- Context – Language, currency, sales channel and customer group, which influence every request.
It is important to distinguish this from administration: the Store API is not intended for creating products, maintaining prices or processing orders in the backend. It exclusively represents the customer’s view. For administrative tasks, there is a separate interface: the Admin API.
Store API vs. Admin API
Shopware 6 provides two separate APIs that are often confused. Distinguishing between them is fundamental for any headless project:
| Feature | Store API | Admin API |
|---|---|---|
| Perspective | Customer / Storefront | Administration / Back office |
| Typical user | End customer in the shop | Shop operator, ERP, PIM |
| Example action | Add product to basket | Create product or change price |
| Authentication | Sales channel access key | OAuth token with admin rights |
| Use in a headless setup | Frontend / App | Data maintenance, integrations |
Rule of thumb: Everything a customer is permitted to do in the shop is handled via the Store API. Everything an employee does in the backend or a connected system (ERP, PIM, CRM) runs via the Admin API. A decoupled frontend uses almost exclusively the Store API; the Admin API comes into play for data imports and system integrations.
How the Store API works in a headless setup
In a decoupled architecture, communication takes place at runtime: Every time a visitor opens a page, the frontend fetches the necessary data fresh via the Store API. For this to work, every request requires two things: an access key, which identifies the sales channel (passed in the sw-access-key), and – as soon as a shopping basket or a customer session is involved – a context token (header sw-context-token), which maintains the session across multiple requests.
A typical workflow
A concrete example illustrates this. A customer visits a product page in a headless Shopware shop that uses the Shopware frontends (Nuxt):
- The frontend retrieves the product data via
POST /store-api/product/{id}and receives the title, description, price, images and availability back as JSON. - The customer clicks ‘Add to basket’ – the frontend calls
POST /store-api/checkout/cart/line-itemand passes thesw-context-tokenso that the shopping basket remains associated with the session. - At checkout, the customer selects a delivery and payment method; the frontend retrieves the available options via the Store API and triggers the order with
POST /store-api/checkout/order.
The backend handles price calculation, stock checks, taxes and rules; the frontend deals solely with presentation and interaction. It is precisely this clear separation that allows the same backend to be used simultaneously for a website, a native app and an in-store checkout terminal – all three communicate via the same Store API.
The exact endpoints, parameters and response formats are described in the official Shopware developer documentation (see the Store API documentation on developer.shopware.com). The complete OpenAPI reference, which can be used to automatically generate clients, can also be found there.
Authentication and Context
The Store API is deliberately designed to be open, as it returns public shop data – after all, every visitor must be able to view product information. It is protected via the sales channel’s access key, not via a traditional login. Only when things become personalised (shopping basket, customer account, order) is the context token added. This token represents the session: it remembers who the customer is, which language and currency have been selected, and which customer group applies. For headless developers, understanding this context mechanism is crucial, as many errors in practice stem from the fact that the sw-context-token is lost between requests, causing the shopping basket to appear ‘empty’.
If you do not wish to build your own HTTP handling, use the official API client from the Shopware Frontends project. This TypeScript client encapsulates authentication, context token management and the request/response schemas, and is technology-neutral – meaning it can also be used outside of Vue or Nuxt, for example in a React or Next.js application.
When the Store API becomes relevant for a project
The Store API isn’t automatically the better choice simply because it sounds ‘modern’. It becomes relevant as soon as a project deliberately omits Shopware’s built-in Twig frontend. This is an architectural decision with consequences: opting for a headless approach shifts the work that the classic storefront provides out of the box (templates, theme editor, ready-made checkout interface) onto your own development team. Without this team, the workload increases significantly.
Using the Store API makes particular sense in three scenarios: when the frontend itself is the key competitive advantage and exceeds the capabilities of Twig; when the same commerce data is to be fed to multiple channels (website, native app, point-of-sale, marketplace); or when there is a dedicated front-end team with its own release cycle. For a traditional, standard shop whose strength lies in its product range, service or price, the supplied storefront generally remains the more cost-effective choice – it uses the same Store API, but comes ready-packaged.
The Store API is closely linked to concepts such as headless commerce, composable commerce and the MACH architecture. It is the concrete technical building block that turns the abstract ‘API-first’ idea into lived practice at Shopware.
Store API, caching and performance
A common misconception is that a headless front-end is automatically faster. Speed does not result from decoupling in itself, but from clean caching and well-thought-out rendering. Because the Store API returns fresh data with every request, a front-end that queries all endpoints anew for every page view would place an unnecessary load on the back-end and appear slow. In practice, therefore, a multi-tiered approach is used: Shopware caches Store API responses on the server side (HTTP cache); the frontend pre-fetches static or rarely changing content via mechanisms such as Incremental Static Regeneration or a CDN layer; and only truly dynamic requests – such as the shopping basket, login, checkout – go directly to the API. Anyone who ignores this interplay ends up with a technically correct but slow headless front-end.
Closely linked to this is the issue of search engine visibility. As the Store API only provides data and no ready-made HTML pages, the frontend must perform server-side rendering (SSR) so that search engines can see the content. A front-end assembled entirely within the browser runs the risk of the crawler encountering a blank page. The Store API itself is neutral in this regard – it provides the data; whether this results in a crawlable page is determined by the front-end’s rendering strategy. This is precisely where the wheat is separated from the chaff in projects: the Store API provides the building blocks, whilst the team is responsible for the performance and SEO architecture, often in collaboration with an experienced agency.
Frequently asked questions about the Store API
Is the Store API free?
Yes. The Store API is part of Shopware 6, including the Community Edition. There are no additional licence costs solely for using the interface. Costs arise from the development and operation of your own front end, not from the API itself.
What is the difference between the Store API and GraphQL?
The Store API is a REST API with fixed endpoints and JSON responses. GraphQL is an alternative query approach in which the client specifies exactly which fields it needs. Shopware relies on the REST-based Store API for the customer-facing interface; an official GraphQL interface is not included as standard.
Do I need the Shopware front-ends to use the Store API?
No. The Store API is technology-neutral. The Shopware front-ends (Vue/Nuxt) are the official, recommended foundation and come with a ready-to-use API client, but any front-end capable of making HTTP requests can access the Store API – including React, Next.js, native apps or other systems.
Does the Store API also work for B2B shops?
Yes. The Store API also covers B2B scenarios – such as corporate accounts, quotation processes and customer-specific prices – provided that the relevant Shopware functions, such as the B2B Components, are active in the backend. The frontend then retrieves this data via the same interface as in the B2C scenario, which makes the Store API a robust foundation even for sophisticated wholesale and manufacturer shops.
Will I lose my Shopware plugins when using the Store API?
Partly. Backend plugins that operate via the backend will continue to work. Plugins that deliver their functionality via storefront templates (Twig) no longer work in a decoupled frontend and must be recreated within your own frontend. This is one of the most important considerations when deciding for or against a headless setup.