Public Content API

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

Die API ist im Premium-Tarif verfügbar. Der gesamte Zugriff erfolgt schreibgeschützt; das Veröffentlichen und Bearbeiten bleibt innerhalb von Nolorem.

Einen API-Schlüssel erstellen

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

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

Der Schlüssel wird nur einmal angezeigt. Speichern Sie ihn sofort in einem Secrets Manager oder einer Umgebungsvariable. Wenn Sie ihn verlieren, widerrufen Sie den Schlüssel und erstellen Sie einen neuen.

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

Wenn Sie einen Schlüssel erstellen, wählen Sie, ob er einen bestimmten Blog oder alle Blogs in Ihrer 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 Ihrer Organisation. Verwenden Sie diesen nur, wenn Sie einen bewussten Grund haben, 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, erstellen Sie einen neuen Schlüssel mit dem gewünschten Bereich, aktualisieren Sie alle Verbraucher und widerrufen Sie anschließend den alten Schlüssel.

Anfragen authentifizieren

Übergeben Sie 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ühren Sie alle API-Aufrufe von Ihrem Backend oder einem serverseitigen Skript aus.

Ihre Blogs auflisten

GET /api/v1/blogs listet die Blogs auf, auf die Ihr 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. Nutzen Sie diesen Endpunkt, um herauszufinden, welche Blogs ein Schlüssel abdeckt, bevor Sie Inhalte abrufen.

Beiträge nach Blog filtern

Alle Content-Endpunkte akzeptieren einen optionalen blog-Parameter. Übergeben Sie 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 Sie blog weglassen, gibt die API Inhalte aus allen Blogs zurück, auf die Ihr Schlüssel zugreifen kann (das Standardverhalten, ohne Breaking Change).

Wenn Sie 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 Ihres 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",
      "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. Nutzen Sie 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 einzelnen Beitrag abrufen

Rufen Sie 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.

Inkrementelle Synchronisierung mit updated_since

Um nur neue oder geänderte Inhalte zu synchronisieren, speichern Sie den Zeitstempel Ihrer letzten erfolgreichen Synchronisierung und übergeben Sie 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ättern Sie durch alle Ergebnisse, bevor Sie Ihren neuen Synchronisierungs-Zeitstempel speichern.

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

Wenn Sie updated_since für die inkrementelle Synchronisierung verwenden, gibt die Standardantwort nur Beiträge zurück, die noch veröffentlicht sind. Wurde ein Beitrag seit Ihrer 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, übergeben Sie include_deleted=true zusammen mit Ihrem 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 Sie bereits aus einer vorherigen Synchronisierung haben
• 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 }
}

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

Wenn Ihr Synchronisierungs-Tool einen Tombstone sieht, ziehen Sie die entsprechende Seite am Ziel zurück oder entfernen Sie sie (setzen Sie 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 Ihres 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 Ihre 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 Ihre 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 Premium-Tarifanforderung 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 Ihnen zu verstehen, wie Ihre 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 Sie die Kennzeichnung sehen, überprüfen Sie Ihre Nutzungsprotokolle. Wenn Sie den Schlüssel absichtlich geteilt haben (zum Beispiel mit mehreren Servern in einem Cluster), überlegen Sie, ob das Zugriffsmuster erwartbar ist. Wenn der Schlüssel möglicherweise durchgesickert oder an unbeabsichtigte Parteien weitergegeben wurde, widerrufen Sie ihn und erstellen Sie 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 Sie ein Limit überschreiten, gibt die API HTTP 429 mit einem Retry-After-Header zurück, der angibt, wie viele Sekunden Sie vor einem erneuten Versuch warten müssen:

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

{ "error": "Rate limit exceeded" }

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

Fehlercodes

Status	Bedeutung
400	Ungültige Abfrageparameter
401	Fehlender oder ungültiger API-Schlüssel
403	Premium-Tarif 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üfen Sie 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. Sie können ihn in Postman, Insomnia oder ein beliebiges OpenAPI-kompatibles Tool importieren.

Einen Schlüssel widerrufen

Um einen Schlüssel zu widerrufen, scrollen Sie in den Einstellungen zum Bereich API-Schlüssel, suchen Sie den Schlüssel anhand seines Namens und klicken Sie 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.