JJourney AI

Architecture

Learn how the admin panel, API, and sites talk to each other, and how a change reaches the live site.

Updated 27 October 20264 min read

This page covers the three parts of Journey AI, the installation model, and the path a change takes from an editor to the live site.

Three parts

PartRole
Admin panelThe web app where editors, users with approval permission, and administrators work. It reads and writes content through the API.
APIStores content in a database, enforces business rules and permissions, and serves JSON to sites. Files live in cloud storage and are served through a CDN.
Site templateA Next.js website. It fetches pages from the API and turns the component tree into React components.
Admin panel ──► API ──► Preview site  (shows preview copies)
                  └───► Live site     (shows published content only)

One instance per installation

Every installation has its own API, database, file storage, and two sites. Shared code is deployed to all installations, but no data is shared between them.

The two-site model

The same site code is deployed twice in every installation:

  • Preview site: Requests preview copies from the API and skips all caching. This is the site shown in an iframe inside the admin panel's component editor. The Inspector is only enabled here.
  • Live site: Fetches published content only and caches pages. Pages refresh in the background at least every 5 minutes, and immediately when the admin panel asks after a save.

The preview is not a mock-up. It is a separate copy of the same site, so editors see exactly how a change will look before it goes live.

How a change travels

The editor saves

An editor changes the title of a published page and clicks Save.

The API writes to the preview copy

The change is written to the page's preview copy. The live record is untouched. If no preview copy exists yet, one is created.

Both sites revalidate

The admin panel sends a revalidation request to both sites. The preview site shows the change right away.

The page goes to approval

A published page has no separate send step: with the save, the status becomes Awaiting approval. Users with approval permission see it in Waiting for you and in notifications.

A user with approval permission approves

The API swaps the preview copy with the live record. If the publish start date has arrived, the page becomes Published; otherwise it is scheduled.

The live site updates

The admin panel requests revalidation again, and visitors see the new content.

See Publishing workflow for the full set of statuses.

Edit and approval model

Journey AI uses a workflow that gives editors immediate feedback while keeping the live publication path separate and reviewable:

  • Save updates only the preview copy; the live record remains untouched. On a published page, saving also sends the change for approval.
  • Send for approval is only used on pages that have never been published; the page becomes Awaiting approval.
  • Approve and publish swaps the preview copy with the live record. Reject returns the page to Awaiting edits; the reject window has no reason field. The editor fixes it and resends it with Send for approval again.
  • Revalidation refreshes the affected page on both preview and live sites so the UI and published output stay aligned.

This creates a safe publishing model: the editor sees the next state, while production remains controlled by approval.

How content is stored

Page content is not stored as HTML. Every page is a component tree. The site walks this tree and renders each node as a React component. The admin panel decides what is said; the site decides how it looks. The same content can appear with a different design on different sites.

Related pages

On this page