Xt4b

Read-API

Eine SEO-Content-API über jeden Beitrag, den Sie geplant haben.

Die API beantwortet die Frage, die ein Report stellt: Was haben wir veröffentlicht, wo, in welcher Sprache, und was sagt der Artikel. Ein Endpunkt pro Bedarf, eine feste Form, nichts zu installieren — und keine Möglichkeit für eine Integration, in Ihre Inhalte zurückzuschreiben.

Mit Ihrer Domain starten Mit Ihrer Domain starten
Die API-Referenz lesen

JSON über HTTPSBearer-Key oder x-api-keyImmer nur lesend

Was können Sie die Content-API fragen?

Zwei Endpunkte, fünf Parameter, ein Envelope. Das ist die ganze Oberfläche — deshalb gibt es keine Client-Bibliothek, die gepflegt werden muss.

Die Kurzfassung

  • Zwei Endpunkte: eine Liste von Beiträgen und ein einzelner Beitrag über seine numerische ID oder über das Präfix slug: und seinen Slug.
  • Filter sind website, status, language, limit (Standard 100, maximal 200) und offset.
  • Jeder Beitrag liefert dieselben 13 Schlüssel auf oberster Ebene; ein noch nicht erzeugtes Feld ist ein leerer String statt fehlend.
  • Die Authentifizierung ist ein Schlüssel auf Kontoebene, gesendet als Bearer-Token oder als x-api-key-Header; das Limit liegt bei 120 Anfragen pro Minute.
  • Sie ist nur lesend. Nichts in der API kann einen Beitrag, ein Datum oder eine Website ändern.
GET /api/v2/posts
Jeder Beitrag des Kontos, neueste zuerst, mit Paginierungs-Metadaten. Die Seitengröße ist standardmäßig 100 und akzeptiert bis zu 200; offset bewegt sich durch den Rest.
GET /api/v2/posts/{id}
Ein Beitrag über seine numerische ID oder über den Slug als `slug:ihr-beitrags-slug`, damit ein CMS einen Beitrag über die URL nachschlagen kann, die es schon kennt.
?website=<domain>
Auf eine Website eingrenzen — die Hauptdomain oder die Blog-Domain, unabhängig von Groß- und Kleinschreibung. Der Filter wird vor dem Zählen angewendet, die Paginierung bleibt also korrekt.
?status=published
Der Status wird exakt verglichen: draft, pending_approval, published, unpublished, in_progress, failed_review. Ungefiltert bekommen Sie alle — auch die, die noch warten.
?language=de
Eine redaktionelle Linie. Nützlich, wenn dasselbe Thema in mehreren Märkten existiert und nur einer davon in diesen Report gehört.
120 requests / minute
Pro Konto, mit einem Retry-After-Header, wenn Sie es überschreiten. Genug für einen nächtlichen Sync und eine interne Live-Suche; kein Scraping-Endpunkt.

Zwei Pfade, zwei Formen

/api/v2/posts ist der aktuelle Pfad, und /api/posts ist ein Alias davon. /api/v1/posts liefert weiterhin die ursprüngliche flache Form, eingefroren, damit eine bestehende Integration weiterläuft; neue Clients sollten mit v2 beginnen. Nur das Beitragsobjekt unterscheidet sich — Authentifizierung, Filter, Statuscodes und Paginierung sind identisch.

Die vollständige Referenz

Jeder Parameter, jedes Feld im Payload und jeder Fehlercode — mit Beispielen zum Kopieren — steht in der Referenz unten. Diese Seite ist die Tour; jene ist der Vertrag. Posts-API-Referenz

Wie ein Beitrag auf der Leitung aussieht.

Dreizehn Schlüssel auf oberster Ebene, jeder immer vorhanden. Drei bündeln zusammengehörige Felder, und der Artikel reist mit seinen Metadaten, ein Consumer muss also nie ein zweites Mal fragen, ob ein Beitrag live ist.

GET/api/v2/posts?status=published&limit=1
Authorization: Bearer xt4b_••••••••••••
{
  "data": [
    {
      "id": "57",
      "status": "published",
      "slug": "seo-content-cost-per-article",
      "title": "Was kostet SEO-Content pro Artikel?",
      "meta": {
        "title": "Was kostet SEO-Content pro Artikel?",
        "description": "Three pricing models and what each one hides."
      },
      "searchIntent": "commercial",
      "keywords": {
        "primary": "seo content kosten",
        "secondary": ["seo content pricing"]
      },
      "images": { "cover": "https://cdn.xt4b.com/…/cover.svg" },
      "language": "de",
      "website": "xt4b.com",
      "publishedAt": "2026-09-11T09:00:04.118Z"
    }
  ],
  "pagination": { "limit": 1, "offset": 0, "total": 7 }
}

Die Antwort ist ein Envelope mit data und pagination. Ein einzelner Beitrag liefert dasselbe Objekt in data, ein Parser bedient also beide Aufrufe.

Felder, die die Pipeline noch nicht erzeugt hat, sind leere Strings statt nicht vorhanden: Ein geplanter Beitrag hat einen Titel, Metadaten, eine Intention und Keywords, aber kein Markdown, kein Cover und kein Veröffentlichungsdatum. Ein Client kann diese Zeile rendern, ohne eine einzige Bedingung für fehlende Schlüssel.

Die Form ist ein Vertrag, keine Bequemlichkeit. Sie ist das, was Xt4bs eigener Blog und seine Search-Console-Panels lesen, eine neue Spalte in der Datenbank kann also nicht still zu einem neuen Feld in Ihrer Integration werden.

Der Artikel und die Akte drumherum.

Die Hälfte des Payloads ist das Stück, das ein Leser sieht; die Hälfte ist die Herkunft, die eine Redaktion oder ein Report braucht.

Der Artikel

  • title — die Überschrift, unter der der Artikel veröffentlicht wird
  • meta.title und meta.description — für das Suchergebnis geschrieben, nicht aus dem Text gehoben
  • markdown — der Artikel als Quelle, also das, was Sie bearbeiten
  • html — derselbe Artikel, vom Publisher gerendert, inklusive Überschriften-Anker

Die Akte

  • id und slug — stabile String-Schlüssel und die URL, unter der der Beitrag liegt
  • status — wo der Beitrag in der Pipeline steht, nicht nur live oder nicht
  • website und language — welche Website, welcher Markt
  • publishedAt — ISO-Zeitstempel, leer solange er noch geplant ist
  • keywords.primary, keywords.secondary und searchIntent — das Briefing, nach dem geschrieben wurde
  • images.cover — das generierte Titelbild

Von null zur ersten Zeile.

Vier Schritte, und der vierte ist eine curl-Zeile, die Sie in ein Terminal oder einen Cron-Job kleben können.

  1. 01

    Ein Konto anlegen und eine Website verbinden

    Die API ist ein Fenster auf Ihre eigenen Beiträge, sie braucht also eine Website und einen Plan dahinter. Der kostenlose Scan zeigt Ihnen die fehlenden Suchanfragen einer Website, bevor Sie etwas verbinden.

  2. 02

    Den Schlüssel aus den Einstellungen kopieren

    Ein Schlüssel pro Konto, angezeigt auf der Einstellungsseite. Ihn neu zu erzeugen widerruft den vorherigen sofort, das ist die ganze Rotation — es gibt keine Client-ID, kein Secret und keine Callback-URL.

  3. 03

    Ihn als Header senden

    `Authorization: Bearer <key>` oder `x-api-key: <key>`. Beides funktioniert an jedem Endpunkt, ein Skript und ein Browser-Tool können also das nehmen, was einfacher ist.

  4. 04

    Anfragen, was Sie brauchen

    Starten Sie mit `?status=published&limit=50`, und grenzen Sie dann mit `website` und `language` ein, sobald Sie die Form kennen. Blättern Sie mit `offset`, statt Beiträge einzeln anzufragen.

Sehen, was die Beiträge erzeugt, die diese API zurückgibt

Drei Aufrufe, kopiert und eingefügt.

Der erste liefert eine Seite live stehender Beiträge, der zweite schlägt einen über den Slug in seiner URL nach, der dritte fragt, was noch auf Freigabe wartet.

Auflisten, was live ist, Website für Website

curl "https://xt4b.com/api/v2/posts?website=xt4b.com\
&status=published&limit=50" \
  -H "Authorization: Bearer $XT4B_API_KEY"

Ein Beitrag, über den Slug in seiner URL

curl "https://xt4b.com/api/v2/posts/\
slug:seo-content-cost-per-article" \
  -H "x-api-key: $XT4B_API_KEY"

Was auf eine Entscheidung wartet

curl "https://xt4b.com/api/v2/posts?status=draft\
&language=de&limit=100&offset=0" \
  -H "Authorization: Bearer $XT4B_API_KEY"

Das Fehler-Envelope

{
  "error": {
    "code": "rate_limited",
    "message": "Too many requests — retry after 12s."
  }
}
Jeder Parameter, jedes Feld und jeder Fehlercode, mit den Antworten, die Sie zurückbekommen

Was damit gebaut wird.

Die vier Integrationen, die zuerst kommen, in der Reihenfolge, in der sie üblicherweise gebaut werden.

  1. 01

    Ein Report, der sich selbst baut

    Holen Sie einmal pro Nacht Beiträge mit status=published und schreiben Sie die Zeilen in Ihr Dashboard. Kein Scraping des eigenen Blogs, keine Tabellen-Abschrift.

  2. 02

    Ihr CMS als Ziel

    Wenn der Blog woanders lebt, nehmen Sie das Markdown (oder das gerenderte HTML), die Metadaten und die Bilder und veröffentlichen es selbst. Die API ist nur lesend, hier kann also nichts überschreiben, was Ihre Redaktion geschrieben hat.

  3. 03

    Interne Suche, die Ihnen gehört

    Filtern Sie nach Website und Sprache, um eine Suchbox oder einen Block mit verwandten Beiträgen über Ihrem eigenen Archiv zu bauen — auch über die noch nicht veröffentlichten Beiträge.

  4. 04

    Eine QA-Schlange

    Fragen Sie status=draft oder failed_review ab und prüfen Sie, was die Pipeline produziert hat, bevor es live geht — mit Ihren eigenen Tools statt mit unseren.

Für Verlage Für WordPress-Websites

Was die API nicht ist.

Sagen wir klar, weil eine Read-API leicht zu viel verspricht.

Kein Generierungs-Endpunkt
Es gibt kein POST, das einen Artikel anfordert. Inhalte werden von der Pipeline gegen einen Plan geplant und geschrieben, und die API berichtet das Ergebnis.
Kein Veröffentlichungs-Endpunkt
Nichts, was Sie senden, kann einen Beitrag, ein Datum oder eine Website ändern. Will ein Client über sein eigenes CMS veröffentlichen, holt er die Beiträge und veröffentlicht dort — der Fehlermodus einer schlechten Integration ist ein fehlender Beitrag, nie ein falscher.
Keine Schlüssel pro Website
Ein Schlüssel pro Konto, mit ?website= als Filter. Einfacher zu rotieren, und es heißt, dass eine Agentur-Integration einmal konfiguriert wird statt pro Kunde.
Kein Versprechen zu Rankings
Sie berichtet, was veröffentlicht wurde und was eine verbundene Search Console zeigt. Eine Position, die es noch nicht gibt, kann sie nicht berichten, und nichts daran garantiert Traffic oder Umsatz — Ranking, Traffic und Umsatz werden weder von dieser noch von einer anderen API garantiert.

Mehr zum Thema

Fragen, die Entwickler stellen.

Auch die beiden dazu, was sie verweigert.

Gibt es einen Endpunkt, der schreibt oder veröffentlicht?

Nein. Die API ist bewusst nur lesend: Sie gibt preis, was die Pipeline geplant und veröffentlicht hat, und nichts daran kann einen Beitrag, ein Datum oder eine Website ändern. Veröffentlicht wird im Dashboard, wo ein Mensch die Entscheidung trifft.

Wie sieht die Authentifizierung aus?

Ein Schlüssel pro Konto, angezeigt in Ihren Einstellungen, gesendet entweder als `Authorization: Bearer <key>` oder als `x-api-key`-Header. Den Schlüssel neu zu erzeugen widerruft den alten sofort, und es gibt kein OAuth-Verfahren, kein Client-Secret und nichts zu installieren.

Brauche ich ein SDK?

Nein. Es ist JSON über HTTPS mit einem Filtersatz und einem Envelope — ein fetch-Aufruf in jeder Sprache oder eine curl-Zeile in einem Cron. Die Antwortform ist fest: Jeder Schlüssel ist bei jedem Beitrag vorhanden, und noch nicht erzeugte Felder kommen als null zurück statt zu fehlen.

Warum werden Markdown und gerendertes HTML beide zurückgegeben?

Weil die meisten Consumer eines davon brauchen. Markdown ist das, was Sie bearbeiten und speichern; das HTML ist der Artikel, wie der Publisher ihn rendert, mit Überschriften-Ankern und gehärteten Links, eine Website kann einen Beitrag also ausliefern, ohne Markdown selbst zu parsen. Keines wird zur Anfragezeit abgeleitet — beide werden aus der gespeicherten Zeile gelesen.

Sieht der Schlüssel jede Website des Kontos?

Ja — Schlüssel gelten pro Konto, und Websites werden mit ?website= gefiltert. Für eine Agentur heißt das: eine Integration für alle Kunden, und pro Report muss sich nur der Website-Filter ändern.

Was passiert, wenn ich das Rate-Limit erreiche?

Sie bekommen einen 429 mit einem Retry-After-Header, und der Zähler gilt pro Konto in einem festen Minutenfenster. Blättern Sie mit limit und offset, statt Anfragen pro Beitrag abzufeuern: limit akzeptiert bis zu 200.

Wie bekomme ich einen API-Schlüssel?

Er wird für Sie erzeugt: Legen Sie ein Konto an, und der Schlüssel erscheint auf der Einstellungsseite, fertig zum Kopieren. Es gibt kein Antragsformular, keinen zu registrierenden OAuth-Client und keinen Schlüssel pro Website zu verteilen.

Kann ich nach Zeitraum filtern?

Nein — die Filter sind website, status, language, limit und offset. Beiträge kommen neueste zuerst, ein Zeitfenster ist also ein Durchblättern: Nehmen Sie 200 auf einmal und hören Sie auf, wenn publishedAt älter ist als das Fenster, das Sie interessiert. Das ist Absicht: Ein halb unterstützter Datumsfilter wäre schlechter als ein ehrliches Durchblättern.

Gibt die API auch noch nicht veröffentlichte Beiträge zurück?

Ja, sofern Sie sie nicht herausfiltern. Ein ungefiltertes Lesen liefert jeden Beitrag mit seinem Status, auch Entwürfe, auf Freigabe wartende Beiträge und solche, die das Review nicht bestanden haben — genau das macht eine QA-Schlange möglich. Die meisten Reporting-Integrationen starten mit ?status=published.

Gibt es eine Sandbox oder einen Testmodus?

Nein. Es gibt eine API und einen Schlüssel. Weil die API nur lesend ist, ist es harmlos, sie auf ein echtes Konto zu richten — im schlimmsten Fall liefert ein Fehler Zeilen, die Sie nicht gebraucht hätten.

Wie sehen Fehler aus?

Dasselbe Envelope wie die Daten: ein `error`-Objekt mit einem maschinenlesbaren `code` und einer Nachricht — invalid_api_key (401), invalid_post_id (400), post_not_found (404), rate_limited (429). Nichts gibt einen nackten String zurück, ein Client kann also auf den Code verzweigen, statt Prosa zu parsen.

Kann ich die Daten bekommen, ohne den gehosteten Blog zu nutzen?

Genau dafür wird die API veröffentlicht. Der Blog ist das Standardziel, weil er die Integrationsarbeit vollständig erspart, aber dieselben Beiträge sind als Daten verfügbar, ein bestehendes CMS, ein Static-Site-Build oder ein Data Warehouse kann also das Ziel sein.

Ein Schlüssel, alle Websites

Auf Ihrer Domain veröffentlichen, als Daten lesen.

Erstellen Sie ein Konto und verbinden Sie eine Website: Die Pipeline erzeugt die Beiträge, der Blog liefert sie aus, und die API gibt Ihnen die Zeilen, um es zu belegen.

Blog automatisierenMit Ihrer Domain starten

Markdown und gerendertes HTML120 Anfragen pro Minute3 Tage kostenlos, ohne Kreditkarte