DELIVERY API FOR CONTENT ACCESS

One access point to every piece of content, for any frontend.

Everything you manage or connect in Laioutr, you retrieve through the Delivery API – read-only, structured, ready to use right away.

The Delivery API is the read-only access point to your Laioutr platform. Every piece of content administered with us or managed through connected systems behind it – text, structured data, images – can be retrieved through it. That means you can power not just our own frontends with content, but essentially any frontend you want to run.

Read-only access to structured content, images included · Laioutr · Berlin

Frontend first

Frontends need more than plain text today

Product pages, landing pages, mobile apps, or partner websites – content needs to be structured and immediately usable everywhere, not just flowing text in an editor. That's exactly what a delivery layer provides.

One place for content, many output channels

Maintaining content in several places because every frontend runs its own system costs time and consistency. A central platform with read-only API access solves that, without every team needing its own island solution.

A headless CMS entry point without the complexity overhead

Many established headless CMS solutions come with a feature set most teams never fully use. The Delivery API deliberately focuses on where the actual need is: retrieving content reliably, without unnecessary technical overhead.

Agents controlling laioutr frontend
The definition

What is the Delivery API at Laioutr?

The Delivery API is the read-only interface through which you retrieve every piece of content administered on your Laioutr platform or managed through connected backend systems behind it. That includes structured text as well as images and other media, because content at Laioutr means more than just running text.

That means you can power not only your own Laioutr frontend, but essentially any frontend you want to run – from your own app to a partner's website. One content store, any number of output channels.

Schema foundation from Studio

Every content type you create in Studio automatically gets a clear schema. That exact schema is what the Delivery API returns, so every frontend knows from the start which fields to expect.

What that means:
No guesswork when integrating, just predictable, structured responses.

Simple enough for what teams actually need

Instead of hundreds of endpoints and configuration options, the Delivery API delivers exactly what most teams actually need: reliable, structured content retrieval. Without hours of onboarding.

What that means:
Fewer features, but the right ones – for a fast, uncomplicated start.

Read-only, deliberately scoped

The Delivery API delivers content, it doesn't change it. Write access runs through other, separate paths – that separation keeps content retrieval simple, predictable, and safe.

What that means:
A frontend that only reads can't break anything.

Backend agnosticism

Because Orchestr brings together data from any connected backend, the Delivery API doesn't just deliver content from Laioutr itself, but also from the systems behind it – through the same interface, in the same format.

What that means:
One central retrieval point, no matter how many systems work in the background.

Images and media included

Content at Laioutr isn't just text. Images, graphics, and other media stored in Laioutr are retrievable through the same interface as structured data – metadata included, exactly what a frontend needs to render them.

What that means:
One API for all of your content, not two separate systems for text and images.

How content delivery evolved

The Delivery API isn't an invention out of nowhere, it's the deliberate simplification of a development that kept getting more complex.

2000–2010

Generation 1

Monolith CMS

Could: Content and delivery in one system. Built simply for a single website.

Couldn't: Reuse content across multiple frontends. Every new output meant a new island solution.

Typical: WordPress, TYPO3, classic editorial systems.

2015-2020

Generation 2

Headless CMS

Could: Deliver content to multiple frontends through an API. Editorial and development got decoupled.

Couldn't: Manage images and structured content together consistently in many cases. Setup often stayed involved.

Typical: Contentful, Sanity, the first headless generation.

2020-2025

Generation 3

Enterprise Headless CMS

Could: Extensive enterprise features, many content models, many integrations.

Couldn't: Stay simple. For smaller and mid-sized teams, the feature set quickly became a burden rather than a help.

Typical: Storyblok, extensive enterprise CMS suites.

2025+

Generation 4

Focused delivery API

Can today: Reliably deliver content – text, structure, and images – to any frontend through a single, read-only API, without hours of onboarding.

Deliberately not: The full feature set of established enterprise CMS platforms. Instead, exactly the functionality the market we serve needs, and nothing more.

Typical: Laioutr Delivery API.

Every generation solved a real problem and built new complexity along the way. The Delivery API deliberately takes a step back toward simplicity: making all content available to read, without the extra weight most teams never actually need.

USE CASES

What you can build with the Delivery API

Because the Delivery API makes every administered piece of content available to read, many different use cases arise from it, depending on which frontends and systems you want to power with it.

The examples below show the range, from your own website to entirely separate applications that consume your content.

Power your own frontends

Your Laioutr storefront or your own marketing website pulls content directly from the Delivery API – one content store, consistent across all of your own channels.

Connect third-party frontends

A mobile app, a kiosk system, or a partner's frontend can pull the same content, without you having to build a second content management setup.

Store content centrally

Instead of scattering content across several systems, everything lives in one place – text, structure, and images – and gets distributed from there to every output.

Deliver image content alongside text

Product images, graphics, or icons are delivered through the same interface as text – one call, one complete content package.

Bring in backend systems

Whatever additional systems are connected behind Laioutr can be retrieved through the same Delivery API, without building separate integrations for every frontend.

Start without overhead

No extensive setup, no weeks of onboarding – the Delivery API is deliberately built so your first request works quickly, instead of demanding months of integration work.

Agentic frontend management platform
Architecture

How the Delivery API is built technically

For the tech leads in the room: the Delivery API is built on the same schemas that get defined in Studio for content types. Every request returns structured, predictable responses, including media references for images and other assets.

Honestly, this is still a young product, without the feature set of established content platforms. But it delivers exactly what most teams need for reliable, read-only content access, and it keeps growing with real requirements.

Clear boundaries

What the Delivery API is not

So expectations stay realistic, three clarifications about a still-young product.

Pricing Plans Comparison
Compare differences
Nicht das
Sondern das
Was die Delivery API nicht ist
Damit die Erwartungen realistisch bleiben — drei Klarstellungen zu einem noch jungen Produkt.
Ein vollausgestattetes Enterprise-Headless-CMS
Der Unterschied zwischen jahrelang gewachsenem Funktionsumfang und einem fokussierten Werkzeug für den echten Bedarf.
Eine Content-Plattform mit dem Reifegrad und Funktionsumfang von Contentful oder Storyblok. Das sind wir ehrlicherweise noch nicht.
Ein fokussiertes Delivery-Werkzeug: genau die Funktionen, die der Markt braucht, den wir bedienen — nicht mehr.
Eine Schreib-Schnittstelle
Warum lesender Zugriff eine bewusste Entscheidung ist, keine Einschränkung aus Versehen.
Ein Weg, um Content zu erstellen oder zu bearbeiten. Das passiert weiterhin in Studio, nicht über die Delivery API.
Ein reiner, lesender Zugriff — schnell, vorhersehbar, ohne Risiko, versehentlich Content zu verändern.
Ein Ersatz für strukturierte Content-Modellierung
Die Delivery API liefert, was Studio modelliert — sie ersetzt die Modellierung nicht.
Ein eigenständiges Content-Modellierungs-Tool. Modelliert wird in Studio, abgerufen über die Delivery API.
Die konsequente Ergänzung zu Studio: Was ihr dort an Content-Typen definiert, kommt hier strukturiert wieder raus.
FOR WHOM

Who is the Delivery API relevant for?

Teams running more than one frontend

A fit if:
You need content for more than one frontend, for instance a website and an app.

You want to avoid maintaining content twice in separate systems.

You want a central content store that delivers read-only to every output channel.

Teams with third-party frontends

A fit if:
You want to power partner websites, kiosk systems, or external apps with your content.

You want a content source that isn't tied to Laioutr's own frontends.

You're looking for a lean, standardized interface instead of one-off exports.

Teams looking for a simple starting point

A fit if:
You want to enter the headless CMS world without fighting through a huge feature set.

You need exactly the functionality your use case requires, nothing more.

You prefer honesty about current maturity over a feature arms race.

WHAT WE BUILD ON

The principles behind the Delivery API

Frontend openness

The Delivery API makes no distinction between your own applications and external ones

Any frontend, yours or someone else's

Safety through restriction

Read-only access rules out accidental changes from the start

Only reading, never changing

Honest maturity

We don't promise a feature set we don't deliver today

Fit for the market we serve

Content, complete

No separate system for images, everything runs through the same interface

Text, structure, and images from one source

FAQ

The Delivery API is new, so questions come up — we answer the most important ones here

Everything administered on your Laioutr platform or managed through connected backend systems behind it – structured text content, metadata, and images included. You query for a content type and get back the matching, schema-valid data.

No, deliberately not. The Delivery API is read-only. Creating and editing content still happens in Studio or through your connected backend systems – that separation keeps retrieval simple and safe.

Yes, that's exactly what it's built for. Whether it's your own mobile app, an internal tool, or a partner's frontend – as long as it can make HTTP requests, it can pull content through the Delivery API.

Yes. Images and other media stored in Laioutr are part of the content and get delivered through the same interface as structured text, metadata included.

Honestly, not yet in full feature scope, those are established products with years of a head start. But the Delivery API covers exactly the functionality needed for reliable, read-only content access, and it grows with real requirements from the market we serve.

No. The Delivery API works independently of whichever frontend ends up displaying the content. You can just as well use it to power a completely separate or third-party system with content.

Preferably in a conversation. We'll look together at which frontends and systems you want to power with content, and show you how quickly your first request through the Delivery API can be up and running.

Book a demo mobile
CONTENT OUTLOOK

Want to deliver your content across more than one frontend?

Let's talk about your frontends and systems. We'll tell you honestly what the Delivery API delivers today, where its limits are, and how quickly a first request can be up and running.

"After 30 minutes, we knew Laioutr makes our replatforming feasible." - Daniel B., CEO, hygibox.de