Skip to main content

Content first: How Enonic works headlessly

Solving headless headaches with Enonic’s content first approach.

While headless CMS is a preferred platform for developers and solves a lot of challenges, it is not without its own issues. To rectify several of the potential shortcomings, Enonic offers a hybrid architecture to satisfy both developers and editors alike.

But that is only part of the success formula. In order to really succeed as a headless CMS, the platform of your choice should follow the “content first” principle. All serious vendors today model their content for reuse and treat content as a primary—while presentation is secondary.

Now, let us take a look at how Enonic approaches “content first” in practice.

Also, see how Enonic fits your requirements:

Spec sheet: How Enonic fits your requirements

Content types

Enonic is content-oriented rather than page-oriented, meaning that every content item must have a specific content type, like “article,” “person,” “case study,” “product,” “shortcut,” “image,” “file,” “folder,” “landing page,” and “site.”

Each content type includes a specific set of fields that define it. For instance, the content type “person” may include fields for “first name,” “last name,” “image,” and “biography,” while “landing page” may only include a “name” field.

Several metadata fields are common to all content types, including “display name,” “language,” “permissions,” “modified by,” “create date,” and more.

Schema system

Content types are defined through Enonic’s schema system, which enables developers to create various rich and complex forms throughout the CMS.

The schema system provides a 1:1 mapping between schema fields and corresponding document properties. For example: a text input called “title” is mapped to a property called “title” in the underlying document structure.


Several standard input types are included in the schema system, together with advanced form components like “ItemSets” and “OptionSets” for creating nested sets of data and optional sets of data, respectively.

See also: Rocketpower your content operations with Enonic »

Input types

Enonic offers a wide range of input types to create custom content types. Input types available for Enonic schemas include “TextArea,” “ContentSelector,” “HtmlArea,” “GeoPoint,” “Date,” and “RadioButton.”


If you want to share a set of fields across several content types, you can extract them into a mixin. Then you simply add a reference to the relevant mixin within forms of the content types of your choice.

An example could be metadata you would want across different content types, but defined in one place. Mixins can be used in content types, component descriptors, and the site.xml file.


This is an alternative for those who want to append a separate form of fields rather than injecting fields inside content type’s form. With X-Data you can define a set of fields that can be applied to different content types, marking a separate step in the content form.

An example of X-Data is the SEO Meta Fields app, where certain fields are appended into different content types, with no need to change each content type.


Publishing power! Enonic Content Studio cheat sheet »

Tree structure

Working with content in Content Studio is done through a tree structure called “content navigator.” This type of navigation is familiar from operating systems, and allows the user to browse through content by opening and collapsing child contents under a parent content.

A powerful, fuzzy search with faceting is also available, as is a standard actions menu consisting of creating new, edit, delete, duplicate, move, sort, preview, publish, and unpublish different content items.


Roles and access management

With Enonic you can easily administer user roles and access management. You can define custom roles—like administrator, editor, and contributor—and assign users to the different roles, and even group users for your convenience.

Within Content Studio, you can further assign which users have rights to perform certain actions. For example: who has the right to publish or who can edit content items.


Headless API

To complete our “content first” package, Enonic comes with a powerful GraphQL API, available as both an application and a library.

As should be clear by now, our content first approach makes Enonic ideal for serving content via API. It also enables developers to instantly make use of the powerful search capabilities provided by the underlying NoSQL storage.

Spec sheet: How Enonic fits your requirements

headless cms
content first
hybrid cms
content management
content types