Public Content API

Die Public Content API bietet dir schreibgeschützten programmatischen Zugriff auf die Blogbeiträge in deiner Nolorem-Organisation. Nutze sie, um Inhalte in eine Drupal-Website, ein individuelles Frontend, eine mobile App oder ein beliebiges externes System zu übertragen, das deine Blog-Daten benötigt.

Die API ist auf jedem bezahlten Tarif verfügbar, einschließlich einer Testphase. Ein aktives Abonnement ist erforderlich; der gesamte Zugriff erfolgt schreibgeschützt, und das Veröffentlichen und Bearbeiten bleibt innerhalb von Nolorem.

Einen API-Schlüssel erstellen

Nur Organisations-Admins können API-Schlüssel erstellen.

1. Scrolle in den Einstellungen zum Bereich API-Schlüssel (nur für Admins sichtbar).
2. Klicke auf API-Schlüssel erstellen.
3. Gib einen aussagekräftigen Namen für den Schlüssel ein (zum Beispiel "Drupal-Website" oder "Content-Sync-Skript").
4. Wähle den Geltungsbereich für den Schlüssel (siehe unten).
5. Kopiere den auf dem Bildschirm angezeigten Schlüssel. Er beginnt mit nlr_live_.

Der Schlüssel wird nur einmal angezeigt. Speichere ihn sofort in einem Secrets Manager oder einer Umgebungsvariable. Wenn du ihn verlierst, widerrufst du den Schlüssel und erstellst du einen neuen.

Einen Geltungsbereich für den Schlüssel wählen

Wenn du einen Schlüssel erstellst, wählst du, ob er einen bestimmten Blog oder alle Blogs in deiner Organisation abdeckt.

Blog-gebundener Schlüssel (empfohlen): der Schlüssel ist an einen einzelnen Blog gebunden. Er kann nur auf Beiträge, Kategorien und Tags aus diesem Blog zugreifen. Falls der Schlüssel jemals durchsickert oder geteilt wird, ist nur der Inhalt dieses einen Blogs offengelegt.

Organisationsweiter Schlüssel: der Schlüssel hat Zugriff auf alle Blogs in deiner Organisation. Verwende diesen nur, wenn du einen bewussten Grund hast, mit einem einzigen Schlüssel auf mehrere Blogs zuzugreifen.

Das Bereichs-Badge auf jedem Schlüssel in der Liste zeigt an, an welchen Blog der Schlüssel gebunden ist, oder "Alle Blogs" bei einem organisationsweiten Schlüssel. Der Geltungsbereich wird bei der Erstellung festgelegt. Um den Geltungsbereich zu ändern, erstelle einen neuen Schlüssel mit dem gewünschten Bereich, aktualisiere alle Verbraucher und widerrufe anschließend den alten Schlüssel.

Anfragen authentifizieren

Übergib den Schlüssel im Authorization-Header jeder Anfrage:

Authorization: Bearer nlr_live_your_key_here

Beispiel mit curl:

curl https://nolorem.io/api/v1/posts \
  -H "Authorization: Bearer nlr_live_your_key_here"

Die API ist Server-zu-Server. Es gibt keine CORS-Header, daher können Browser-Clients sie nicht direkt aufrufen. Führe alle API-Aufrufe von deinem Backend oder einem serverseitigen Skript aus.

deine Blogs auflisten

GET /api/v1/blogs listet die Blogs auf, auf die dein Schlüssel zugreifen kann. Die Struktur der Antwort ist identisch, unabhängig davon, ob der Schlüssel blog-gebunden oder organisationsweit ist.

curl https://nolorem.io/api/v1/blogs \
  -H "Authorization: Bearer nlr_live_your_key_here"

Antwort:

{
  "data": [
    { "id": "uuid", "slug": "my-blog", "name": "My Blog" },
    { "id": "uuid", "slug": "company-news", "name": "Company News" }
  ]
}

Ein blog-gebundener Schlüssel gibt genau einen Eintrag zurück (den gebundenen Blog). Ein organisationsweiter Schlüssel gibt alle Blogs zurück. Nutze diesen Endpunkt, um herauszufinden, welche Blogs ein Schlüssel abdeckt, bevor du Inhalte abrufst.

Beiträge nach Blog filtern

Alle Content-Endpunkte akzeptieren einen optionalen blog-Parameter. Übergib entweder die Blog-UUID oder ihren Slug:

# Nach Slug filtern
curl "https://nolorem.io/api/v1/posts?blog=my-blog" \
  -H "Authorization: Bearer nlr_live_your_key_here"

# Nach UUID filtern
curl "https://nolorem.io/api/v1/posts?blog=550e8400-e29b-41d4-a716-446655440000" \
  -H "Authorization: Bearer nlr_live_your_key_here"

Wenn du blog weglässt, gibt die API Inhalte aus allen Blogs zurück, auf die dein Schlüssel zugreifen kann (das Standardverhalten, ohne Breaking Change).

Wenn du einen blog-gebundenen Schlüssel verwenden und ?blog= auf einen anderen Blog verweisen lassen, gibt die API 403 Forbidden zurück. Dies verhindert das Erraten, welche Blogs in einer Organisation existieren.

Derselbe blog-Parameter funktioniert bei /api/v1/categories und /api/v1/tags.

Beiträge auflisten

GET /api/v1/posts gibt eine paginierte Liste von Beiträgen für die zugänglichen Blogs deines Schlüssels zurück. Standardmäßig werden veröffentlichte Beiträge zurückgegeben, 20 pro Seite.

curl "https://nolorem.io/api/v1/posts?status=published&per_page=50" \
  -H "Authorization: Bearer nlr_live_your_key_here"

Antwort:

{
  "data": [
    {
      "id": "uuid",
      "blog_id": "uuid",
      "title": "My blog post",
      "slug": "my-blog-post",
      "excerpt": "Lead paragraph...",
      "language": "en",
      "available_locales": ["en", "nl"],
      "locale_slugs": {
        "en": "my-blog-post",
        "nl": "mijn-blogbericht-over-contentgeneratie"
      },
      "category": "Technology",
      "tags": ["AI", "Productivity"],
      "featured_image_url": "https://...",
      "published_at": "2026-06-01T10:00:00Z",
      "updated_at": "2026-06-10T14:30:00Z",
      "html": null
    }
  ],
  "meta": { "page": 1, "per_page": 50, "total": 123 }
}

Das Feld html ist in Listen-Antworten immer null. Nutze die Detail-Endpunkte, um den vollständigen Beitragstext zu erhalten.

Verfügbare Filter

Parameter	Beschreibung	Beispiel
blog	Blog-UUID oder Slug (Standard: alle zugänglichen Blogs)	blog=my-blog
status	published, draft oder scheduled (Standard: published)	status=published
language	ISO 639-1 Sprachcode	language=nl
category	Kategoriename (Groß-/Kleinschreibung wird nicht beachtet)	category=Technology
tag	Tag-Name (Groß-/Kleinschreibung wird nicht beachtet)	tag=AI
updated_since	ISO 8601 Datum/Uhrzeit; nur nach diesem Datum geänderte Beiträge	updated_since=2026-06-01T00:00:00Z
page	Seitenzahl, beginnend bei 1	page=2
per_page	Elemente pro Seite, max. 100	per_page=100

Einen Beitrag in einer anderen Sprache abrufen

language und locale sehen sich ähnlich und tun das Gegenteil voneinander. Lies das einmal, dann verwechselst du sie nicht mehr.

language filtert. Es entscheidet, welche Beiträge zurückkommen, und gleicht dabei die Sprache ab, in der ein Beitrag geschrieben wurde. ?language=nl gibt deine niederländischen Beiträge zurück und lässt die englischen weg.

locale filtert nichts. Es gibt die Beiträge zurück, die du ohnehin bekommen hättest, aber in der angefragten Sprache, sofern davon eine vollständige Übersetzung existiert. ?locale=nl auf dem Listen-Endpunkt gibt weiterhin jeden Beitrag zurück: Beiträge mit einer vollständigen niederländischen Übersetzung kommen mit ihrem niederländischen title, slug, excerpt, seo_title und seo_description zurück, alle übrigen unverändert.

Nutzt du heute ?language=? Für dich ändert sich nichts. Lässt du locale weg, behält jedes Feld, das du bereits gelesen hast, genau den Wert von vorher, und language behält die Bedeutung, die es immer hatte. Der einzige Unterschied sind die beiden Felder weiter unten, die ab jetzt in jeder Antwort enthalten sind.

# Jeder Beitrag, auf Niederländisch, wo eine vollständige niederländische Übersetzung existiert
curl "https://nolorem.io/api/v1/posts?locale=nl" \
  -H "Authorization: Bearer nlr_live_your_key_here"

# Ein Beitrag, auf Niederländisch, samt HTML-Text und den Alt-Texten der Bilder
curl "https://nolorem.io/api/v1/posts/550e8400-e29b-41d4-a716-446655440000?locale=nl" \
  -H "Authorization: Bearer nlr_live_your_key_here"

Auf den beiden Detail-Endpunkten umfasst die Projektion auch html und den alt-Text jedes Eintrags in images, sodass die ganze Seite in einer einzigen Sprache steht.

Eine Übersetzung, die noch nicht fertig ist, zählt nicht. Ist die Übersetzung für die angefragte Sprache nicht abgeschlossen, bekommst du die Quellversion unverändert zurück, niemals eine Seite, die auf halbem Weg die Sprache wechselt. language benennt in jeder Antwort weiterhin die Quellsprache, ob du locale mitgibst oder nicht.

Der Slug-Endpunkt akzeptiert auch einen übersetzten Slug. Mit gesetztem locale trifft /api/v1/posts/slug/{slug} auch den Slug, den diese Sprache trägt, und nicht nur den Quell-Slug: /api/v1/posts/slug/contentkalender-vullen-met-geautomatiseerde-contentgeneratie?locale=nl liefert denselben Beitrag wie seine englische Adresse. Der Quell-Slug wird zuerst versucht und gewinnt immer, damit ein übersetzter Slug niemals die eigene Adresse eines anderen Beitrags überdecken kann. Lässt du locale weg, trifft nur der Quell-Slug, und ein übersetzter Slug allein ergibt 404.

Wissen, welche Sprachen ein Beitrag hat

Du musst nicht raten und keine Anfrage pro Sprache stellen. Jeder Beitrag trägt zwei Felder, in Listenantworten genauso wie in Detailantworten:

{
  "language": "en",
  "available_locales": ["en", "nl"],
  "locale_slugs": {
    "en": "why-automated-content-generation-fixes-your-empty-calendar",
    "nl": "contentkalender-vullen-met-geautomatiseerde-contentgeneratie"
  }
}

available_locales listet jede Sprache auf, in der dieser Beitrag ausgeliefert werden kann, immer einschließlich seiner Quellsprache. Eine Sprache steht dort nur, wenn ?locale= darin tatsächlich eine vollständige Seite liefern kann; deshalb kannst du die Liste bedenkenlos für deine hreflang-Tags verwenden.

locale_slugs gibt den Slug an, den jede dieser Sprachen trägt. Beachte, dass sich die beiden Slugs oben um mehr als ein übersetztes Wort unterscheiden: Jede Sprache wählt ihren eigenen Slug rund um ihr eigenes Ziel-Keyword, du kannst den einen also nicht aus dem anderen ableiten. Nutze diese Zuordnung, um die URL pro Sprache auf deiner eigenen Website zu bauen.

Einen einzelnen Beitrag abrufen

Ruf einen Beitrag anhand seiner UUID ab, um den vollständigen HTML-Text zu erhalten:

curl "https://nolorem.io/api/v1/posts/550e8400-e29b-41d4-a716-446655440000" \
  -H "Authorization: Bearer nlr_live_your_key_here"

Oder anhand seines Slugs:

curl "https://nolorem.io/api/v1/posts/slug/my-blog-post" \
  -H "Authorization: Bearer nlr_live_your_key_here"

Beide geben ein einzelnes PublicPost-Objekt zurück (nicht in einem data-Array verpackt), wobei das Feld html befüllt ist.

Beide Endpunkte verwenden standardmäßig status=published, genau wie der Listen-Endpunkt oben. Wird ein Beitrag anhand der ID oder des Slugs abgerufen und ist er nicht veröffentlicht, liefert die Anfrage jetzt 404, es sei denn, du fügst ?status=draft oder ?status=scheduled hinzu.

Inkrementelle Synchronisierung mit updated_since

Um nur neue oder geänderte Inhalte zu synchronisieren, speichern du den Zeitstempel deiner letzten erfolgreichen Synchronisierung und übergib ihn beim nächsten Durchlauf als updated_since:

# Erste Synchronisierung: alle veröffentlichten Beiträge abrufen
curl "https://nolorem.io/api/v1/posts?per_page=100" \
  -H "Authorization: Bearer nlr_live_your_key_here"

# Nachfolgende Synchronisierungen: nur seit der letzten Synchronisierung geänderte Beiträge
curl "https://nolorem.io/api/v1/posts?updated_since=2026-06-10T14:30:00Z&per_page=100" \
  -H "Authorization: Bearer nlr_live_your_key_here"

Blättere durch alle Ergebnisse, bevor du deinen neuen Synchronisierungs-Zeitstempel speicherst.

Nicht veröffentlichte oder gelöschte Beiträge erkennen

Wenn du updated_since für die inkrementelle Synchronisierung verwendest, gibt die Standardantwort nur Beiträge zurück, die noch veröffentlicht sind. Wurde ein Beitrag seit deiner letzten Synchronisierung in Nolorem zurückgezogen oder gelöscht, verschwindet er einfach aus den Ergebnissen, ohne dass ein Signal gegeben wird, ihn am Ziel zu entfernen.

Um dieses Signal zu erhalten, übergib include_deleted=true zusammen mit deinem updated_since-Zeitstempel:

curl "https://nolorem.io/api/v1/posts?updated_since=2026-06-10T14:30:00Z&include_deleted=true" \
  -H "Authorization: Bearer nlr_live_your_key_here"

Die Antwort enthält wie gewohnt alle aktiven Beiträge sowie minimale Tombstone-Einträge, die am Ende von data angehängt werden. Jeder Tombstone hat:

• id, die Beitrags-UUID, die du bereits aus einer vorherigen Synchronisierung hast
• status, den aktuellen Status des Beitrags oder "deleted", wenn er dauerhaft entfernt wurde
• updated_at, wann die Änderung erfolgt ist
• deleted, true, wenn der Beitrag gelöscht wurde, false, wenn er lediglich zurückgezogen oder in einen Entwurf verschoben wurde

{
  "data": [
    { "id": "...", "title": "Live post", "updated_at": "..." },
    { "id": "...", "status": "draft", "updated_at": "...", "deleted": false },
    { "id": "...", "status": "deleted", "updated_at": "...", "deleted": true }
  ],
  "meta": { "page": 1, "per_page": 20, "total": 1, "tombstones": 2 }
}

Verwende meta.tombstones, um zu wissen, wie viele Tombstone-Einträge angehängt sind. meta.total spiegelt immer nur die aktiven Beiträge wider.

Wenn dein Synchronisierungs-Tool einen Tombstone sieht, ziehst du die entsprechende Seite am Ziel zurück oder entfernst du sie (setzt du zum Beispiel den passenden Drupal-Node auf zurückgezogen oder Entwurf).

Ohne include_deleted=true ist das Verhalten identisch mit dem vor dieser Änderung, es werden nur aktive, veröffentlichte Beiträge zurückgegeben.

Kategorien und Tags auflisten

Zwei Endpunkte geben die vollständige Kategorie- und Tag-Taxonomie deines Blogs zurück. Diese sind nützlich für externe Tools, die Nolorem-Kategorien oder -Tags ihrer eigenen Taxonomie zuordnen müssen (zum Beispiel ein Drupal-Connector, der Nolorem-Kategorien Drupal-Vokabularbegriffen zuordnet). Beide akzeptieren den blog-Parameter.

# Alle Kategorien für deine Organisation (oder den gebundenen Blog)
curl "https://nolorem.io/api/v1/categories?blog=my-blog" \
  -H "Authorization: Bearer nlr_live_your_key_here"

# Alle Tags für deine Organisation (oder den gebundenen Blog)
curl "https://nolorem.io/api/v1/tags?blog=my-blog" \
  -H "Authorization: Bearer nlr_live_your_key_here"

Beide geben die vollständige Liste in einer einzigen Antwort zurück (nicht paginiert):

{ "data": [{ "id": "uuid", "name": "Marketing" }, { "id": "uuid", "name": "Technology" }] }

Es gelten dasselbe Bearer-Token, dieselbe Anforderung eines aktiven Abonnements und derselbe posts:read-Geltungsbereich wie für die Beitrags-Endpunkte.

Nutzungsanalysen pro Schlüssel

In den Einstellungen kann jede Schlüsselzeile erweitert werden, um Nutzungsanalysen anzuzeigen:

• Anfragen (letzte 24 Std. / gesamt), wie viele API-Aufrufe dieser Schlüssel getätigt hat.
• Verschiedene Quellen, wie viele verschiedene IP-Adressen und Client-Anwendungen diesen Schlüssel kürzlich verwendet haben.
• Zuletzt verwendet, der Zeitstempel der letzten authentifizierten Anfrage.

Diese Analysen helfen dir zu verstehen, wie deine Schlüssel verwendet werden, und unerwartete Muster zu erkennen.

Kennzeichnung für geteilte Schlüssel

Wenn ein Schlüssel innerhalb kurzer Zeit eine große Anzahl verschiedener IP-Adressen aufweist, kann Nolorem ihn als "möglicherweise geteilt oder kompromittiert" kennzeichnen. Die Kennzeichnung erscheint als bernsteinfarbene Warnung in der Schlüsselzeile. Der Schlüssel funktioniert weiter und es wird keine automatische Aktion ausgeführt, dies ist ein beratendes Signal.

Wenn du die Kennzeichnung siehst, überprüfe deine Nutzungsprotokolle. Wenn du den Schlüssel absichtlich geteilt haben (zum Beispiel mit mehreren Servern in einem Cluster), überlegst du, ob das Zugriffsmuster erwartbar ist. Wenn der Schlüssel möglicherweise durchgesickert oder an unbeabsichtigte Parteien weitergegeben wurde, widerrufst du ihn und erstellst du einen neuen, um den Zugriff zu beschränken.

Ratenbegrenzungen

Für jeden API-Schlüssel gelten diese Grenzwerte:

• 60 Anfragen pro Minute
• 5 000 Anfragen pro Tag

Wenn du ein Limit überschreitest, gibt die API HTTP 429 mit einem Retry-After-Header zurück, der angibt, wie viele Sekunden du vor einem erneuten Versuch warten musst:

HTTP/1.1 429 Too Many Requests
Retry-After: 43

{ "error": "Rate limit exceeded" }

Implementiere exponentielles Backoff für zuverlässige, langlaufende Synchronisierungsskripte.

Fehlercodes

Status	Bedeutung
400	Ungültige Abfrageparameter
401	Fehlender oder ungültiger API-Schlüssel
403	Aktives Abonnement erforderlich, Schlüssel fehlt der posts:read-Geltungsbereich, oder blog-gebundener Schlüssel mit nicht übereinstimmendem ?blog=-Wert verwendet
404	Beitrag nicht gefunden
429	Ratenbegrenzung überschritten (Prüfe den Retry-After-Header)

Maschinenlesbare Spezifikation

Die vollständige API-Spezifikation im OpenAPI 3.1-Format ist verfügbar unter:

GET /api/v1/openapi.json

Dieser Endpunkt ist nicht authentifiziert. Du kannst ihn in Postman, Insomnia oder ein beliebiges OpenAPI-kompatibles Tool importieren.

Einen Schlüssel widerrufen

Um einen Schlüssel zu widerrufen, scrolle in den Einstellungen zum Bereich API-Schlüssel, Suche den Schlüssel anhand seines Namens und klicke auf Widerrufen. Der Schlüssel funktioniert sofort nicht mehr. Bereits authentifizierte, laufende Anfragen werden abgeschlossen, aber keine neuen Anfragen mit dem widerrufenen Schlüssel werden erfolgreich sein.