What is the best practice for authentication and tokens in Store API?

The best practice for Shopware Store API authentication is to separate tokens by purpose and keep customer-facing authentication isolated from admin or integration access. Your storefront, mobile app, or headless frontend should use the Store API with a sales channel access key and customer context tokens—not Admin API credentials. That keeps permissions limited and reduces the blast radius if a token leaks.

In a standard Shopware setup, the Store API uses three main layers of authentication: the sales channel access key, the context token, and optional customer login tokens. The access key identifies the sales channel. The context token tracks cart and session state. Customer authentication links the context to a logged-in account without exposing admin-level access.

Most security problems happen when developers hardcode tokens in frontend code, reuse Admin API credentials in headless apps, or fail to rotate access keys after staging environments get exposed. Shopware already gives you the structure for secure token handling—you mainly need to avoid bypassing it with shortcuts.

How Store API authentication works

Every Store API request starts with the sales channel access key. This key is attached in the request headers and tells Shopware which storefront or channel the request belongs to. Think of it as a public storefront identifier rather than a secret password.

Once a visitor starts browsing or adds items to the cart, Shopware creates a context token. That token stores cart state, customer group, currency, shipping rules, and login state. The frontend must persist and reuse this token across requests. If you regenerate it too often, carts reset unexpectedly (this catches many headless builds).

When a customer logs in, the login request upgrades the existing context instead of creating a separate authentication layer. That means cart continuity stays intact between guest and authenticated sessions. In practice, this is why you should never manually overwrite context tokens after login unless you intentionally want a fresh session.

Best practices we recommend on real projects

Keep Admin API tokens completely separate

The Admin API is not designed for public storefront traffic. We still see stores exposing integration credentials inside frontend JavaScript bundles because developers want quick access to product data. Don’t do this. The Store API already covers storefront operations safely.

Store context tokens server-side where possible

HTTP-only secure cookies are safer than localStorage for most storefronts. LocalStorage makes token theft easier if your frontend ever gets hit by an XSS issue. For mobile apps, use encrypted device storage instead of plain async storage.

Rotate sales channel access keys during deployments

Staging URLs leak surprisingly often through screenshots, QA tools, or preview deployments. If a sales channel key gets indexed or shared publicly, attackers can hammer Store API endpoints without restriction. Rotating keys after environment cloning is a simple fix that many teams skip.

Rate-limit authentication endpoints

Customer login and password reset routes should sit behind rate limiting or WAF protection. Shopware handles part of this already, but larger stores usually add Cloudflare, Fastly, or edge-level controls to reduce credential stuffing attempts.

Never trust frontend pricing logic

Cart totals, promotions, customer group discounts, and shipping calculations must always be validated server-side through Shopware context rules. Frontends should display values—not decide them.