Diil Content API: deine Website, unser Content

Du baust die Website. Das Team deines Kunden pflegt Texte, Bilder und Preise. Die Diil Content API sitzt dazwischen und reicht deinem Code sauberes JSON — damit nie wieder jemand einen Pull Request aufmachen muss, nur um einen Tippfehler im Hero zu fixen.

#Was ist die Diil Content API?

Diil ist ein visueller Website-Editor mit angeschlossenem CRM. Die Redaktion ändert Inhalte an zwei Stellen: im CRM oder direkt auf der Live-Seite im Live-Modus — Überschrift anklicken, tippen, speichern. Die Content API ist die Tür (nur lesend), durch die deine Website an diese Inhalte kommt.

Anders gesagt: Es ist die API eines Headless CMS. Wir speichern und liefern die Inhalte, du behältst die volle Kontrolle über das Frontend — Stack, Design, Hosting, Build-Pipeline. Wir fassen dein HTML nie an, und du musst nie ein Admin-Panel bauen.

#So funktioniert's

Die ganze Architektur passt in ein Bild:

  Redaktion                   Diil                              Deine Website
  ─────────                   ────                              ─────────────

  CRM ────────┐
              ├──►  Seiten → Sektionen → Blöcke ──►  Content API ──►  fetch() ──►  deine Templates
  Live-Modus ─┘     (jede Änderung erhöht die        nur lesend       x-crm-key    React, Vue, HTML…
  (auf deiner Site)  Content-Version der Site)       JSON über HTTPS

1. Die Redaktion schreibt. Inhalte sind in Seiten, Sektionen und Blöcke gegliedert, jeweils mit einem kurzen Marker wie home, hero oder hero_title. Über Marker findet dein Code die Dinge. Mehr dazu unter Wie Inhalte organisiert sind.
2. Deine Website liest. Ein einziger GET-Request mit Site-Key liefert eine komplette Seite — jede Sektion, jeden Block, jede Übersetzung, die du angefragt hast.
3. Änderungen kommen von allein an. Jede Bearbeitung im CRM erhöht die Content-Version der Site, also bekommt schon der nächste Request frische Daten. Besucher sehen sie wegen Browser- und CDN-Cache eventuell etwa eine Minute später — siehe Caching & ETag.

Die Redaktion soll lieber direkt auf deinen echten Seiten klicken, statt Formulare auszufüllen? Ein Script-Tag und ein paar data-crm-*-Attribute — das ist Live-Editing, und es läuft auf derselben API.

#Was du damit bauen kannst

Alles, was einen HTTP-Request schicken und JSON parsen kann, kann Diil nutzen. Kein SDK zu installieren, kein Framework-Lock-in.

• Next.js, Nuxt, Astro, SvelteKit — auf dem Server fetchen, mit Revalidation cachen, statisch-schnelle Seiten mit editierbaren Inhalten ausliefern.
• Plain HTML + JavaScript — eine Landingpage auf beliebigem Hosting, ein fetch() und fertig.
• Single-Page-Apps mit React oder Vue — der Site-Key ist absichtlich öffentlich, die API aus dem Browser aufzurufen ist also völlig okay.
• Mobile Apps — Onboarding-Texte, Promo-Banner und FAQs, die sich ohne neues Store-Release ändern.
• Mehrsprachige Websites — jeder Textblock kommt als Sprach-Map; frag eine Sprache oder mehrere in einem Request ab.
• Blogs — Posts mit Cover, Autor, geplanter Veröffentlichung und Pagination über /v1/blog.

#Ein Vorgeschmack in 10 Sekunden

Hier ist ein Block — die Headline der Startseite —, per Marker abgefragt. Setz deinen eigenen Key ein, und es läuft genau so:

curl "https://back.sitecog.com/content/v1/blocks/hero_title?section=hero&lang=en" \
  -H "x-crm-key: pk_3f9c2a7e1b4d4c0e8a6f5b2d9c1e7a40"

const res = await fetch('https://back.sitecog.com/content/v1/blocks/hero_title?section=hero&lang=en', {
  headers: { 'x-crm-key': 'pk_3f9c2a7e1b4d4c0e8a6f5b2d9c1e7a40' },
});
const block = await res.json();

console.log(block.content.en); // "Earbuds that mute the city"

{
  "id": 95,
  "marker": "hero_title",
  "name": "Hero title",
  "type": "text",
  "multilang": true,
  "updatedAt": "2026-09-20T16:33:23.000Z",
  "content": { "en": "Earbuds that mute the city" }
}

Das war's. Text kommt als Sprach-Map, Bilder als { "file": "https://…" }, Links als { url, target, title } — alle Formen findest du unter Blocktypen.

#Die API auf einen Blick

Alle Endpoints liegen unter https://back.sitecog.com/content, alle sind GET (und HEAD), alle liefern JSON.

#Ein paar Dinge, die wir für dich richtig gemacht haben

• Ein Request pro Seite. Kein Wasserfall aus Fetches — die Seite kommt mit allem drin.
• Zugriff per Marker, nicht per ID. Antworten sind Objekte mit Markern als Keys, also funktioniert page.content.hero einfach.
• Öffentliche Keys, nur lesend. Ein Site-Key kann nur veröffentlichte Inhalte einer einzigen Site lesen und ist deshalb im Browser-Code sicher. Siehe Site-Keys.
• Ehrliche Sprachen. Frag die Sprachen, die du brauchst, mit ?lang=en,de ab. Eine fehlende Übersetzung fehlt einfach — den Fallback bestimmst du (so geht's).
• HTTP-Caching eingebaut. Jede erfolgreiche Response trägt ein ETag, also bekommst du mit If-None-Match ein günstiges 304 Not Modified.
• Großzügige Limits. 300 Requests pro Minute pro IP und 600 pro Key — mit ein bisschen Caching kommst du da nie hin. Details unter Rate-Limits.

#Wie geht's weiter?