How Sitecore Page Builder Talks to Your Next.js App: A Sequence Diagram Explained

 

How Sitecore Page Builder Talks to Your Next.js App: A Sequence Diagram Explained

When a content author opens a page in the SitecoreAI Page builder and starts editing, it feels like magic. The page appears, exactly as visitors will see it, and every text field and component is editable right there in the browser. But behind that smooth experience is a carefully choreographed conversation between Sitecore and your Next.js application.

In this post, I’ll walk through that conversation using a sequence diagram, one of the most useful tools in a solution architect’s toolkit.

Why a Sequence Diagram?

Most architecture diagrams show what exists: systems, databases, and connections. A sequence diagram shows something different: what happens, in what order. Time flows from top to bottom, each participant gets a vertical line called a lifeline, and arrows show messages passing between them.

For understanding a flow like editing, where several systems call each other in a chain, nothing beats a sequence diagram.

Meet the Participants

The diagram has five participants. The Author is the person editing content. The Page builder is SitecoreAI’s visual editor. The Render API and the Page route both live inside the editing host, which is a special instance of your Next.js app that never serves public visitors and exists only to support editing. Finally, the Preview GraphQL endpoint supplies draft, unpublished content.

The colors tell you who owns what: teal boxes are hosted by Sitecore, and coral boxes are part of your editing host, which your team builds and maintains.

The Flow, Step by Step

Steps 1 and 2: The author opens a page, and the Page builder sends a request to the editing host’s Render API route. This request carries details like which item, language, and site to render, along with a secret token.

Step 3: The Render API checks that the secret is valid. This self-arrow, looping back to its own lifeline, shows work happening inside one participant. If the secret is wrong, the request is rejected with a 401 error, which protects your editing endpoints from outsiders.

Step 4: The Render API switches on Next.js preview mode and asks the page route to render the page. Preview mode is important because it skips static generation and renders fresh at request time, so authors always see their latest drafts.

Steps 5 and 6: The page route fetches draft content from the Preview GraphQL endpoint. What comes back is not just content but also metadata describing every placeholder, component, and field on the page.

Steps 7 to 9: The rendered HTML travels back up the chain to the Page builder, which uses that metadata to make each part of the page editable for the author.

Notice the arrow styles: solid arrows are requests, and dashed arrows are responses coming back.