How Storyblok's Version History Preview Works Under the Hood

When an editor selects a previous version in Storyblok’s Visual Editor, the frontend updates instantly if the bridge is set up correctly. No page reload, no extra API call.

How it works

The version history preview uses the same bridge that powers live editing. When a version is selected, Storyblok doesn’t ask the frontend to fetch that version from the API. It sends the content directly through the bridge’s input event.

From the frontend’s perspective, there’s no difference between:

• an editor typing a new headline

• an editor selecting a version from three weeks ago

Both trigger the same input event. The event.story object contains the full story data, and the frontend renders it.

Step by step

1. Editor opens the Visual Editor and loads a story

2. The bridge connects and starts listening for events

3. Editor opens version history and selects a version

4. Storyblok sends an input event through the bridge with event.story containing that version’s data

5. The frontend receives it, updates the reactive content, and the components re-render

No special handling needed. The bridge does the work.

Why no extra code is needed

Frontend components are pure renderers. They receive content as props and render it. They don’t care whether the content is the current draft, a live edit, or a version from last month.

As long as the bridge sends a story object, the components render it. Stateless rendering logic means the same code path handles live editing, version history, and normal page loads.

The bridge event

When a version is selected, the input event carries the full story object:

bridge.on('input', (event) => {
  // event.story contains the selected version's full data
  // event.story.content has all content fields for that version
  // event.story.published_at reflects that version's dates
})

event.story.content is the complete content of the selected version: all fields, all nested blocks, exactly as they were when that version was saved.

What this means for your implementation

If your frontend already supports the bridge for live preview, version history preview works automatically. Nothing to implement. Same input event, same callback, same rendering pipeline.

The only requirement: your components must be reactive. When new content arrives through the bridge, the UI must update. In Svelte with $derived or React with state, this happens naturally.

One thing to keep in mind: data your frontend fetches separately (resolved relations, articles loaded via additional API calls) won’t be part of the version history preview. The bridge only sends the story’s own content. Loader-injected fields need to be preserved from the original load, which is the same pattern required for regular live editing.