Integration

Storyblok content alongside your commerce backend

Editors get visual editing in Storyblok. Developers get the Nuxt storefront. Commerce data stays in Norce or Shopware.

Storyblok is the headless CMS Frntkey uses for editorial content, landing pages, and translations. The commerce engine continues to own product, pricing, and orders. The two systems split responsibilities cleanly.

  • Visual editing for editors
  • Component-mapped bloks
  • Multi-locale workflows
  • Clean separation from commerce
  • Translations on every field

Benefits

Editors work where they like

Marketing builds campaigns in Storyblok. Developers ship storefront components in code.

Backend untouched

Product data, pricing, and orders stay in Norce or Shopware. Storyblok handles content only.

Translations included

Field-level i18n keys on every blok. Editors translate pages without leaving the CMS.

Component parity

Storyblok bloks mirror the storefront component library, so what editors compose is what visitors see.

Visual editor live preview

The Storyblok editor renders the actual Nuxt frontend in its preview pane, no separate staging needed.

What Storyblok owns

Storyblok is the content layer. Marketing landing pages, blog posts, glossary entries, footer content, navigation copy, hero variants, and translations all live there. Editors get a visual editor with a structured component model that maps to the storefront component library.

What the commerce backend owns

Product data, pricing rules, inventory, and orders stay in Norce or Shopware. Frntkey reads from both systems and renders one storefront. Editors never edit commerce data in Storyblok and developers never edit catalog data in code.

How translations work

Storyblok exposes field-level i18n on every blok. The Frntkey site reads the language-suffixed field per locale, so the EN page and the SV page are the same story rendered with different field values. Editors translate inline without managing parallel page trees.

How we work

  1. Component mapping

    We map the storefront component library to Storyblok bloks. Editors get the same building blocks as the storefront ships.

  2. Content model setup

    Page types, fields, and translatable surfaces are defined. The content team confirms editorial workflow before going live.

  3. Editor onboarding

    A short walkthrough on the visual editor, translation flow, and publishing. Most teams are productive on day one.

Frequently asked questions

Do I need a separate CMS license?
Storyblok is licensed separately by you. Frntkey integrates with your existing Storyblok space or sets one up at delivery.
Can editors create new pages without developer help?
Yes. Frntkey ships a component library exposed as Storyblok bloks. Editors compose pages from those.
How are translations handled?
Field-level i18n on each blok. The Frntkey site reads the language-suffixed field per locale.
Can we add custom components?
Yes. New components are added in code and exposed to editors as new Storyblok bloks. The bloks land in the same visual editor.
What about workflow approvals?
Storyblok supports draft, review, and publish states. Frntkey reads draft in development and published in production by default.

Ready to talk?

See how Frntkey fits your stack. Book a 30-minute demo.

Book a demo