Samuel was our speaker at the Content Strategy Lausanne meetup on March 12th.
Join our community and learn about Content Strategy!

Today content is accessible on various platforms: website, apps, television, social media. With the increasing development of IoT objects, the headless CMS trend is raising. From a copywriting perspective, it is a nightmare to provide custom content for all these channels. Is API first CMS the solution?

When Samuel Pouyt chose to use a headless CMS for the European Respiratory Society, he did not know where he was going. He took the risk of trying a new approach to content management. The API first approach changed his way of working while simplifying it. He made many learnings, some of them because of implementation errors.

Liip: What is an API first CMS?
Samuel: It is a CMS that does not have a front-end and only exposes an API. API stands for Application Programming Interface. An API is a standardized and documented way for applications to communicate. Read here to understand better what an API is.
An API first CMS that only offers an API and no frontend is called a “pure” API first CMS. It is opposed to other mixed forms of API first CMS that offers a little bit of frontend.
In a “pure” API first CMS, content is not mixed with html or context dependent formatting. In a “pure” API first CMS, the CMS does not influence how and where the content is presented. The medium formats the content according to its needs. The medium can be a device, a connected object, a website (a phone, a web application, a social media, a newsletter, a TV, etc.)

Why did you choose this type of CMS for the European Respiratory Society?
Samuel: Content management became unmanageable. We had up to 26 instances of a CMS and a few other unrelated CMS’s. We needed to find a solution. It was difficult to manage updates, redistribution and aggregation of content dispatched in different systems. We also had to handle technical migrations, security updates and patches. We spent an increasing amount of time for maintenance instead of developing new features and updates.
When we started thinking about developing an app, it was my opportunity to try an innovative solution. How could we distribute the content? Write an API on top of our existing CMS’s? I made the case for API first CMS’s. I showed how we would save time in maintenance, development (backend and frontend) and how easy it would be to redistribute content. My manager understood the issue. He agreed to go ahead with my solution of API first CMS.

Liip: What were your challenges during the implementation?
Samuel: Challenges with API first CMS’s are very subtle and not obvious at first sight. First of all, menu management is trivial in a classic CMS, in an API first CMS it is not…Secondly, the front-end needs to be truly decoupled from the API. It is really easy to implement some logic in the frontend that somehow transforms the content. But that transformation will not be available for other systems when they call the content API. Finally, caching is another area that needs extra care as the frontend needs to be notified when content changes in a completely separate system.

If you are further interested in menu management, read my tutorial How to manage menus with Cloud CMS about the solution we implemented at the European Respiratory Society.

With an API first CMS comes flexibility big time: how do you ensure that the content edition team has a clear view on what’s important?
Samuel: It depends who controls flexibility. In my opinion, flexibility is not in the hands of the content edition team. The flexibility here is for the the developer. For the content edition team, nothing changes. The content edition team has a UI where they can manage and organise content. On the other hand developers have total flexibility in what technology they use, how they implement it, how they query content etc. Let’s say that the content edition team has access to the configuration of the CMS, in the worst case, the frontend will not display anything… as changes will have to be implemented in code too… Therefore I would recommend to have a clear understanding of what the content edition team wants to do, and how they want to do it, then everything is straight forward.

Liip: How does an API first CMS change the work and process of the copywriting team?
Samuel: Copywriters need to be trained to think differently about content. Typically, copywriters think about pages, and how the text and images will look like in the context of a page. Copywriters are often used to create content in CSM called WYSIWYG (What You See Is What You Get).
In a CMS that does not have frontend and in a world where your content can end up on so many media (website, apps, social media, newsletters, tv, etc.) copywriters have to come back to the essence: the copy. Sometimes images will be used, sometime not, or a video will be added etc. the copywriter does not control that. Of course this is not always possible, and previews can be implemented, even a website can be rendered “in a future state” to let copywriters verify that it it looks how they wish. With an API first CMS this is extra development, it is not a preview button somewhere on the editors’ UI.

Liip: How did your development team work with the copywriting team to help them create content suitable to be used in an API first CMS? I expect they had to change their writing process?
Samuel: The change has been gradual, we have introduced our API First CMS among the other CMS’s we were using. At first the change impacted only a few users. Gradually the change impacted the whole company. This gave us a chance to train first the most technical members of our copywriting team. It allowed us to fix a lot of small issues and miscomprehension. Eventually, we organized a training for all content editors. In collaboration with the communication department, we created an “onboarding” kit, that included: a style guide (specific formatting of text for the ERS), a general guide on how to write on the web, and a technical guide on markdown (a text format) and how to create/edit/publish/schedule/etc. articles.

Liip: What did you do with the content of the website when you changed the CMS? Did you migrate or did you rewrite all the content?
Samuel: Both… We introduced the API first CMS at the same time as a long overdue migration of the main website. The communication team had reorganised the content and menus for some page. We migrated other pages. With an API first CMS the ingestion of content is really easy as normally you have API endpoints that let you write content. Migration scripts are therefore easier to write.

An API first CMS can also mean that you have to build lots of standard stuff (such as SEO meta information) from scratch. How did you for now ensure these kind functionality for content editors were still available w/out going the extra mile and re-develop it?
The European Respiratory Society’s frontend are developed with Vuejs and Laravel. These open source ecosystems are really rich and many developers have already contributed useful plugins.

For this reason, I used “plugins” that allowed to generated all the meta tags. I also went the extra mile by developing exactly what we needed to improve our content discovery: a search engine and Natural Language Processing “modules” to extract information and classify our content. The search engine and Natural Language Processing “modules” benefited from the API first approach. Content can easily be modified by search engine and Natural Language Processing “modules” by calling the correct endpoints.

Today, there are a lot of misconceptions with API first CMS. It is correct that you have to build a whole frontend. It is often wrong that building a whole frontend takes more time than developping or adapting a Wordpress theme. For example, making sure that all outputs of that CMS are correctly overwritten is time-consuming.

Liip: When would you recommend an API first CMS? For what kind of company or what kinds of needs?
Samuel: If you manage more than one website, or if you need to publish content across different systems, I would recommend an API first CMS. If you are for example a publishing house or a fashion house and that you manage a lot of media and you have the budget, checkout big name CMSs such as Arc Publishing or Adobe. If you need a simple website or blog go for a Wordpress like website, or even simpler solution such as Wix.

The API first CMS landscape is changing very fast. There is a convergence happening. On the one hand, some providers propose easy ways to have a frontend on top of their APIs and, on the other hand, Non-API first CMS start proposing APIs. There are very few API first CMS that have a level of maturity that make them enterprise grade content CMS.

Liip: What do you mean by fully integrated ecosystem?
Samuel: For example, Adobe CMS, the Arc Publishing ecosystem or Chorus Publishing suite (Vox Media) are not API first CMS but fully integrated ecosystem. They are expensive and come with complex workflows management capabilities and many publishing pipelines. For example, they integrate the photographers’ camera into complex workflows and publishing pipelines.
For example, let’s say that you want to create a printed fashion catalogue, a magazine and a website to sell you content. The pictures do not go directly to the website, but are integrate in a publishing workflows. You organise a photo shooting, and the pictures are taken are right away named and uploaded in the DAM of the CMS , ready for review and selection. Copywriters ad text and all this content gets published on the online, shop, magazine and catalogue. Copywriter work on Indesign for the catalogue, and share the text for the website, and other media.

Liip: Do you think API first CMS can compete with such integrated ecosystem?
Samuel: No API first CMS that I have heard of can compete (yet?) with integrated ecosystems like Adobe CMS, the Arc Publishing ecosystem or Chorus Publishing suite (Vox Media). The only API first CMS that has similar advanced features is Cloud CMS. We chose Cloud CMS at the European Respiratory Society after checking different API first CMS. Many of the CMS in this list are very young and do not have the feature that you can expect for enterprise grade CMS such as content versioning, publishing workflows, right managements, etc.

If you want to compare headless CMS, read A List of Content Management Systems for JAMstack Sites.

Liip: Let’s summarise, integrated ecosystems and API first...
Samuel: So if you are working in media, maybe it makes sense to go for a CMS that can integrate with your publishing software such as InDesign. If you just have to build a small website, maybe go for wordpress. But if you think about content as a service in your infrastructure, go for an API first CMS. For me the trigger would be questions such as “How do we get the content from our CMS in the App?” as soon as content as to appear in different places, and API of some sort will be needed, considering an API first CMS can save you a lot of time and money.

Liip: Thank you for the interview Samuel!