Hybrid headless CMS
One CMS. Web pages and JSON.
A hybrid headless CMS delivers the same content as finished web pages or as structured data. In Forrit, content types, entries and pages are managed once. The HTML channel serves complete pages built from your components, and the JSON channel serves pure JSON to apps and custom front ends.
01 · Definition
What is a hybrid headless CMS?
A hybrid headless CMS delivers the same content in two ways: as finished web pages, or as structured data for any front end. It combines the page-based editing of a traditional CMS with the structured content and API delivery of a headless one.
In Forrit, both ways start from the same content types, entries and pages, and every change goes through the same governed workflow.
How hybrid headless works in Forrit
Model content once with content types and entries
Organise it into pages
Publish through the HTML channel, the JSON channel, or both
Serve each channel from a delivery tier separate from the CMS
What hybrid headless gives you
Managed web pages
Forrit renders complete web pages from your components, ready for marketing sites and large web estates.
Headless JSON
The same content is delivered as pure JSON for apps and custom front ends.
One content model
Content types, entries and pages are managed once, whichever channel delivers them.
One governed workflow
Task branches, preview, approval and audit history apply to every change, in both channels.
02 · Compared
How does hybrid headless compare with traditional and headless CMS?
A traditional CMS keeps the page but ties content to one website. A pure headless CMS frees the content but often loses the page. Hybrid headless is designed to keep both.
| Capability | Traditional CMS | Headless CMS | Forrit hybrid headless |
|---|---|---|---|
| Page-based editing | Yes | Often limited | Yes, in both channels |
| Structured, reusable content | Limited | Yes | Yes, with content types and entries |
| JSON and API delivery | Rarely native | Yes | Yes, through the JSON channel |
| Front-end freedom | Tied to the CMS | Yes | Yes, or let Forrit render the pages |
| Preview in context | Yes | Often custom-built | Yes, in Forrit or in your own front end |
| Page-level SEO and metadata | Yes | Often assembled from other tools | Yes, on every page and in the JSON |
| Delivery separated from the CMS | Usually coupled | Yes | Yes, with one-way Airlock Publishing |
Generalised categories, not named products. Individual platforms vary.
03 · Two delivery channels
What is the difference between the HTML and JSON channels?
The difference is who renders the experience. Through the HTML channel, Forrit renders complete web pages from your component templates. Through the JSON channel, Forrit delivers the content as pure JSON, and your own front end renders it.
Everything behind the channels is shared: the same content, the same pages, the same workflow and the same separate delivery tier. Read more about how Forrit keeps the page in a headless setup.
Choosing a channel
Use the HTML channel when Forrit should render the site
Use the JSON channel when your own front end renders it
Use both when a website and an app share content
Channel capabilities
- HTML channel
Complete web pages
Forrit renders full pages from your component templates. Developers extend them with the .NET SDKs.
- HTML channel
Fast launches from shared components
Launch new sites and pages from components and templates you already have, with no separate front end to maintain.
- JSON channel
Pure JSON, any framework
Content with no markup, ready for React, Next.js, mobile apps, .NET or any other front end.
- JSON channel
Pages, routes and SEO as data
Pages, routes, navigation and SEO metadata are delivered as data. Request whole pages or individual entries.
- Both
Same governance in both
Content types, entries, pages, task branches, preview, approval and localisation work the same in either channel.
- Both
Separate delivery tier
Both channels are served by dedicated delivery services, with one-way Airlock Publishing from the CMS.
04 · Which to choose
Which channel suits which project?
The right channel depends on who renders the experience. Here is how the choice usually plays out for common projects.
| Project | Channel | Why |
|---|---|---|
| Marketing websiteRun by the marketing team | HTML channel | Editors build pages from approved components, with no separate front end to maintain. |
| Estate of many sitesRegional, brand or product sites | HTML channel | New sites launch from shared components and templates, under central governance. |
| Customer mobile appiOS, Android or cross-platform | JSON channel | The app reads structured content and page data, and renders it natively. |
| Custom front endNext.js, React or similar, built in-house | JSON channel | Developers keep their framework. Editors still get pages and page-level SEO. |
| Website and app togetherSharing product content | Both channels | One content team and one approval process support both experiences. |
Both channels can run side by side, from the same content and the same approval process.
05 · Pages in both channels
How does a page work in each channel?
In the CMS, a page is the same whichever channel publishes it. Editors build it from components and entries, add its route and SEO metadata, and send it for approval.
When it is published, the HTML channel uses each component's HTML template to render the complete page. The JSON channel uses each component's JSON template to output the page as data, and your front end renders it.
One page, two outputs
Editors build the page from components and entries
The page is approved and published once
HTML channel: Forrit renders the complete page from component templates
JSON channel: your front end receives the page as JSON and renders it
What stays the same
Same editing experience
Editors build and manage pages the same way, whichever channel publishes them.
Same SEO and metadata
Page titles, descriptions and metadata travel with the page in both channels.
Preview before publishing
Preview pages in Forrit, or render draft JSON from the task branch in your own front end.
Go deeper
One content platform, delivered your way.
See how Forrit keeps the page in a headless setup, explore the full CMS, and find out how both channels are protected.
- Forrit CMS
Headless CMS
How Forrit keeps the page in a headless CMS: preview, page-based authoring, page-level SEO and one JSON response per page.
- Product
Forrit CMS
Create, govern and reuse content across your digital estate, with structured content, visual page building and headless delivery in one CMS.
- Key benefit
Security
Seven layers of protection, from edge security and Airlock Publishing to secure development and ISO 27001 assurance.
Use the Tab key to move through each testimonial
The Forrit team was remarkable in helping our organization move an existing website from its tenant to the Forrit platform in a very short timescale. From migration, to pre and launch day activities, they flawlessly executed all details as outlined making the transition seamless and hassle free. Post launch, the team has continued to make themselves available to troubleshoot and answer questions when they arise, which has been beyond helpful. We are very happy to have made the transition to Forrit!
Hybrid headless questions, answered
A hybrid headless CMS can deliver the same content either as finished web pages or as structured data through an API. Forrit does this with two delivery channels, HTML and JSON, both fed by the same content types, entries and pages.
A headless CMS only delivers content as data, so every front end has to be built and maintained separately. A hybrid headless CMS can also render web pages itself. With Forrit you choose per project: let Forrit render a marketing site, and deliver JSON to an app or a custom front end.
Use the HTML channel when you want Forrit to render the website from your components. Typical examples are a marketing site run by the marketing team, or an estate of regional or brand sites launched from shared components and templates.
Use the JSON channel when your own front end renders the experience, such as a mobile app or a site built in Next.js or React. The JSON includes pages, routes, navigation and SEO metadata, and you can request whole pages or individual entries.
Yes. The same content types, entries and pages can be published through both channels, so a website and an app can share product content with one content team and one approval process.
Yes. Changes for either channel are made in task branches, previewed, approved and recorded in the audit history. Both channels are served from a delivery tier that is separate from the CMS, using one-way Airlock Publishing.