Headless-Delivery-API

Dies ist eine Entwicklerreferenz. Wenn Sie zum ersten Mal einen Headless-Space einrichten, beginnen Sie mit Einen Headless-Space erstellen.

Jeder Headless-Space stellt seine veröffentlichten Beiträge über eine öffentliche, CDN-cachefähige Lese-API bereit. Es ist keine Authentifizierung und kein API-Schlüssel erforderlich — die API gibt ausschließlich veröffentlichte Beiträge zurück (Entwürfe und geplante Beiträge erscheinen nie), und ein Blog ist per Definition öffentlich.

Die Basis-URL Ihres Space — einschließlich Workspace- und Website-Kennung — wird auf der Seite Delivery API der Website im Kundenportal angezeigt, zusammen mit fertigen Feed-URLs je Sprache. Alle nachfolgenden Pfade sind relativ zu dieser Basis.

Endpunkte

Route	Gibt zurück
`GET /posts`	Veröffentlichte Beiträge, neueste zuerst (nur Zusammenfassungsfelder)
`GET /posts/{slug}`	Ein veröffentlichter Beitrag, vollständiger Vertrag (siehe unten)
`GET /terms`	Kategorien und Tags mit Beitragsanzahl

Query-Parameter (`/posts`)

Parameter	Beschreibung
`language`	Beiträge in einer Sprache (z. B. `de`). Jede Sprache ist ein separater Blog — eine Kampagne pro Sprache.
`category`	Filtern nach Kategorie-slug. Schließt sich gegenseitig mit `tag` aus.
`tag`	Filtern nach Tag-slug. Schließt sich gegenseitig mit `category` aus.
`cursor`	Nächste (ältere) Seite — die `nextCursor` der vorherigen Antwort übergeben.
`before`	Vorherige (neuere) Seite — die `prevCursor` der Antwort übergeben.
`limit`	Einträge pro Seite; Standard und Maximum 50.

language lässt sich mit category oder tag kombinieren: /posts?language=de&category=news ist das „News”-Archiv des deutschen Blogs. /terms?language=de grenzt die Taxonomie auf dieselbe Weise ein.

Paginierung

Listenantworten sind bidirektional: Jede gibt nextCursor (zu älteren Beiträgen) und prevCursor (zu neueren) zurück. Ein null-Cursor bedeutet, dass es in dieser Richtung keine weiteren Seiten gibt — jede Seite wird ausschließlich anhand ihres URL-Tokens gerendert, ohne dass ein Cursor-Verlauf benötigt wird.

Einzelbeitrag-Antwortvertrag

GET /posts/{slug} gibt { post } zurück mit:

id, slug, title, excerpt — Identität und Zusammenfassungstext.
html — der gerenderte, bereinigte Beitragstext. Wurzel-relative Links werden gegen die öffentliche URL Ihrer Website absolutiert. Kann direkt injiziert werden: strenge Tag-Allowlist, keine <script>-/<style>-/on*-Attribute.
blocks — das strukturierte Block-Array, falls Sie das Rendern dem Injizieren von html vorziehen.
metaTitle, metaDescription, keyphrase, categories, tags.
featuredImage, bodyImage — { url, width, height, alt?, caption? }.
og — { title, description, image }, fertig für Open-Graph-Tags.
schema — ein Array von schema.org-JSON-LD-Objekten (HowTo, FAQPage), wenn der Beitrag diese Abschnitte enthält; andernfalls []. Wird außerhalb des Bands geliefert, da der Body-Sanitizer <script> entfernt — geben Sie für jeden Eintrag ein <script type="application/ld+json"> in Ihr Seiten-<head> aus, um für Rich Results in Frage zu kommen. Die entsprechenden Body-Abschnitte tragen die Klassen structura-howto / structura-faq für das Styling.
publishedAt, updatedAt — ISO 8601. updatedAt ist Ihr Revalidierungs-Signal.

Die Listenantwort gibt nur den Zusammenfassungs-Teilsatz zurück — ohne html, blocks oder schema.

Verwendung mit einem Framework

Beim Build oder zur Revalidierungszeit abrufen und die API als Ihr CMS behandeln: