Capability

Headless CMS

Maintain content once, deliver it everywhere. Website, app, screen, newsletter, partner portal.

Explore all features
Headless CMS

Maintain once, deliver everywhere.

Your structure.

Define content types and fields yourself, without a development project.

Ready for editors.

Multilingual, with draft, approval and a tidy media library.

Deliverable anywhere.

Website, app, screen, portal, newsletter, from one source.

Content belongs to you. Not to your website template.

The price list is on the website. And in the app. And on the screen in the branch. And in the newsletter. And in the PDF field sales send out.

When a price changes, a small expedition through five systems begins. Usually one of them is forgotten.

A headless CMS turns that relationship around. The content lives in one place, independent of how it is displayed. Every channel fetches it from there. Change it once, and it changes everywhere.

You decide what your content looks like

In Caymland M4 you create your content types yourself. No development request, no database change, no waiting.

A content type is a description: an "event" has a title, a date, a place, an image, a description and a link to a speaker. You define that in the interface, and from the next click editors can enter events.

Available field types include:

Field typeWhat for
Text, long text, rich textTitles, short descriptions, formatted content
Numbers, yes/no, date, timePrices, quantities, availability, appointments
DropdownsStatus, category, type
Images and filesIndividually or as a gallery
LinksEvent to speaker, product to manufacturer, article to category
ComponentsReusable field groups such as an address or a contact block
Free sectionsEditors assemble pages from building blocks
Automatic slugsSearch-friendly addresses, generated from the title

For formatted text you choose per field what to work with: plain text, Markdown or a comfortable editor. Your editorial team gets the tool that suits them, not the one the system dictates.

Multilingual without the pain

Languages are enabled per content type. A document then exists in several language versions that belong together and are nevertheless edited and approved individually.

That matters more than it sounds: the German version can go live while the French one is still being proofread. A language switcher shows your editors at once which languages already exist and which are missing.

Draft and approval

Every piece of content has a draft state and a published state. Only what is approved is served outwards.

So your editors can work on the next version in peace while the current one is live. And because approval happens per language, an unfinished translation blocks nothing.

A media library that tidies up

Images and files sit in a central library instead of scattered across folders.

  • Replace instead of re-upload: swap an image and it changes everywhere it is used.
  • Usage evidence: before deleting, you see everywhere a file is embedded. No more broken pages.
  • Rename and organise, without references breaking.

Deliver wherever you want

Approved content is available through an open interface. Your website fetches it, your app fetches it, the screen in the branch fetches it, the partner portal fetches it.

  • Public or protected, decided per content type. Public content is freely retrievable, protected content only with an access token.
  • Filter, sort, page right at retrieval, so the other end does not have to load everything.
  • Caching for fast delivery even under heavy traffic.
  • Outbound notifications when a piece of content changes, so connected systems can react at once.

Your website can be built in any technology. The CMS is not interested in which.

The difference: the CMS sits inside the CRM

An ordinary headless CMS knows content. It knows nothing about the person reading it. For that it needs a second system, a connection between the two, and somebody to maintain both.

In Caymland M4, content and contact live in the same application. No add-on module, no overnight synchronisation, no reconciliation that drifts apart over time.

Three things follow from that:

  • A content field can refer to a contact field. A text carries a placeholder for salutation, first name, surname, company, industry or town, and on delivery it shows whatever the contact record holds.
  • Your categories are the same ones. The industry your marketing segments by is the industry your content is sorted by. Not two lists that both want maintaining.
  • You maintain variants instead of programming exceptions. The same content type holds several versions, one per audience. Which one is delivered is decided at retrieval.

Content that fits the person reading it

Personalisation is therefore not a feature sitting next to the CMS but a property of the content itself. It happens in three steps:

  1. Recognise. If the visitor is known, through a click from one of your emails or through recognition on a return visit, M4 supplies their contact record.
  2. Select. Of the available versions, the one that fits is taken: the one for their industry, their region, their role.
  3. Fill in. The placeholders in the text are filled with the values from the contact record.

The most important part is the one considered last: what happens when nothing is known. If even one value is missing, that version is not used at all and the general one is served instead. Nobody ever reads "Hello {{firstname}}". Anonymous visitors see a complete, sensible page, simply not one tailored to them.

That is also the privacy-friendly order of events. Personalisation begins once consent has been given and a person has been recognised. Not before.

This website is the example

What is described here can be checked right now: caymland.com runs on this very CMS.

The feature description you are reading, the success stories, the industry solutions, the customer quotes, the customer logos and the opening section of the home page are all content in Caymland M4, retrieved through the content delivery API. The website itself is built in Next.js and knows nothing about the CMS beyond its address. That is precisely the point of headless: the presentation is replaceable, the content stays.

The opening section of the home page is a content type with several versions, one per industry. Arrive through a link in one of our emails and you see the version for your industry, with your salutation and your name. Arrive for the first time and you see the general one. Both are the same content type and the same mechanism you get for your own channels.

What this looks like day to day

The tourism board. Events, businesses and offers are maintained once and appear on the main website, the partner sites, in the app and in the weekly newsletter. In four languages.

Retail. Product descriptions and promotions come from one source into the online shop, the in-store screen and the printed insert.

The association. The editorial team works on the next edition as a draft, approves it on the appointed day, and every channel follows. No deploy, no appointment with IT.

Questions & answers

Frequently asked questions

01

Do we need developers to create a new content type?

No. Content types and fields are created in the interface. You need developers only once, for how it is displayed in each channel.

02

Can we keep our existing website?

Yes. That is the point of headless. Your website fetches the content through the API, whatever it is built with.

03

How many languages are possible?

As many as you need. Languages are enabled per content type, and approval happens separately per language.

04

What happens to content that has no translation yet?

A request returns exactly the language asked for. Whether and how a fallback language is shown is a deliberate decision by your channel, rather than the wrong language being served unnoticed.

05

Can we protect content?

Yes. Per content type you decide whether retrieval is public or requires an access token.

06

How does the website know who is looking at it?

Through a click from one of your emails, or through recognition on a return visit. Both require consent. Where there is none, or the person is unknown, nothing is personalised: the page stays complete, simply general.

07

What do anonymous visitors see?

The general version, complete and sensible. A version containing placeholders with no value behind them is never delivered at all, so a half-filled greeting cannot occur.

The difference in one sentence

Other systems tie content to a page.Caymland M4 gives it back to you.

Explore all features