// stack · schnittstelle
Eine Facebook-Seite ist für viele Unternehmen der Ort, an dem Neuigkeiten zuerst erscheinen — und die Website ist der Ort, an dem sie ankommen sollen. Die Graph API ist der Weg dazwischen: Über sie lassen sich Beiträge, Veranstaltungen und Seiteninformationen maschinenlesbar abrufen. siteway holt diese Inhalte serverseitig ab und rendert sie selbst, statt ein fremdes Widget in die Seite zu hängen. Diese Seite beschreibt die Technik dahinter: Zugang, Token, Abruf und Zwischenspeicher.
// definition
Die Graph API ist die HTTP-Schnittstelle, über die Anwendungen Daten der Meta-Plattform lesen und schreiben. Ihr Name beschreibt das Datenmodell: Die Plattform wird als Graph gedacht, als Netz aus Objekten und Verbindungen. Die Dokumentation nennt dafür drei Begriffe — Nodes sind einzelne Objekte mit eigener ID, Edges sind die Verbindungen zwischen ihnen, Fields sind die Eigenschaften eines Objekts.
Für eine Website ist davon nur ein kleiner Ausschnitt interessant, nämlich der Page-Node: die Facebook-Seite eines Unternehmens. Er trägt die Seiteninformationen als Felder — die Referenz führt unter anderem Name, Kategorie, Beschreibung, Anschrift, Öffnungszeiten, Telefon, Website und Titelbild — und er hat Verbindungen zu den eigenen Inhalten, allen voran zu den Beiträgen der Seite. Man fordert dabei immer gezielt einzelne Felder an, statt einen fertigen Block zu bekommen.
Praktisch heißt das: Alles, was auf der Facebook-Seite öffentlich zu sehen ist, ist im Prinzip auch maschinenlesbar zu haben — und lässt sich damit an einer zweiten Stelle wieder ausgeben, im eigenen Design und unter der eigenen Domain. Wie so ein Bereich auf der Website dann aussieht und was er kann, beschreibt die Komponente Social Media Newsroom. Hier geht es um die Schnittstelle darunter — und zwar um die Facebook-Ebene. Den Bild-Feed behandelt Instagram im Stack, das berufliche Netzwerk LinkedIn.
// praxis
abruf auf dem server
Die erste Entscheidung fällt vor der ersten Zeile Code: Der Abruf gehört auf den Server, nicht in den Browser. Ein Dienst auf dem eigenen System ruft die Graph API in festen Abständen auf, holt die Beiträge der Seite und legt sie im CMS ab. Das Frontend liest danach nur noch aus dem eigenen Bestand. Für den Besucher entsteht damit ein Feed, technisch ist es eine gewöhnliche Liste — und im Browser läuft dabei nichts von Meta.
Damit das trägt, wandern auch die Bilder mit. Was an einem Beitrag hängt, wird beim Abruf heruntergeladen und in die Medienverwaltung des CMS geschrieben — als eigene Datei, in den Formaten und Größen der Website. Sonst hinge jedes Vorschaubild weiterhin an einem fremden Server, mit allem, was das für Ladezeit, Verfügbarkeit und Datenfluss bedeutet.
Das Zugriffstoken bleibt serverseitig und taucht im Quelltext der Seite gar nicht erst auf. Es liegt in der Konfiguration oder in einer Umgebungsvariablen, nie fest im Template und nicht in der Versionsverwaltung. Ein Token ist laut Dokumentation an die Kombination aus Seite, Administrator und App gebunden — und es läuft ab. Der Erneuerungsweg und die Benachrichtigung beim Ausfall gehören deshalb von Anfang an dazu, siehe Sicherheit & Datenschutz.
Der zwischengespeicherte Bestand ist zugleich die Ausfallsicherung. Antwortet die Schnittstelle nicht oder langsam, merkt der Besucher davon nichts: Der Bereich zeigt weiter den letzten erfolgreich geholten Stand, der Fehler landet im Protokoll und im nächsten Durchgang. Ein Feed, der bei jedem Seitenaufruf live fragt, übernimmt dagegen die Verfügbarkeit und die Antwortzeit einer fremden Schnittstelle als seine eigene.
Und weil die Beiträge als eigenes HTML herauskommen, gelten für sie dieselben Regeln wie für den Rest der Website: lesbare Überschriftenstruktur, echte Links, Alternativtexte an den Bildern, Bedienbarkeit per Tastatur, Lazy Loading und feste Bildmaße. Ein fremdes Widget bringt seine eigenen Antworten auf diese Fragen mit — hier gibt sie das Projekt.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Entwicklerdokumentation von Meta — Objektnamen, Felder und Zugangsregeln im Original. Konkrete Versionsstände und Kontingente nennen wir bewusst nicht: Sie ändern sich, und eine Technikbeschreibung, die damit arbeitet, wäre schon beim Lesen veraltet. Was für ein Projekt gilt, klären wir am Projekt.
// d-01modell
Das Datenmodell der Graph API. Nodes sind Objekte mit eigener ID — Seite, Beitrag, Foto, Kommentar. Edges verbinden sie, etwa eine Seite mit ihren Beiträgen. Fields sind die Eigenschaften, die man je Abruf gezielt anfordert. Man holt also nie „alles“, sondern eine benannte Auswahl.
zweck: struktur
// d-02beiträge
Die Referenz führt am Page-Node Verbindungen zu den eigenen Inhalten — unter anderem zu Feed und Beiträgen sowie zu Fotos, Videos und Alben. Das ist der Stoff für den Newsroom auf der Website: Text, Zeitpunkt, angehängte Medien und der Link zum Original auf der Facebook-Seite.
zweck: newsroom
// d-03seiteninfos
Der Page-Node trägt laut Referenz Felder wie Name, Kategorie, Beschreibung, Anschrift, Öffnungszeiten, Telefon, Website sowie Profil- und Titelbild. Nützlich, wenn Stammdaten an einer Stelle gepflegt werden sollen — auf der Website landen sie dann als Text und als strukturierte Daten.
zweck: stammdaten
// d-04termine
Der Event-Node führt Felder wie Name, Startzeit, Endzeit, Ort, Beschreibung und Titelbild. Der Zugriff ist hier am engsten geregelt: Die Referenz weist darauf hin, dass Events bei Nutzern und Seiten den Facebook-Marketing-Partnern vorbehalten sind. Ob dieser Weg offensteht, klären wir vor dem Konzept.
zweck: terminliste
// d-05zugang
Der Zugang hat drei Stufen: eine App im Entwicklerbereich, ein Seiten-Zugriffstoken aus dem Tausch eines Nutzer-Tokens, dazu benannte Berechtigungen — die Referenz nennt für das Lesen einer Seite unter anderem pages_read_engagement und pages_read_user_content sowie die Features für öffentliche Seiteninhalte. Für den produktiven Einsatz kommt die App-Prüfung mit Anwendungsfall und Nachweisen dazu.
zweck: berechtigung
// d-06laufzeit
Zwei Dinge altern planbar. Token: Meta unterscheidet kurzlebige und langlebige und weist darauf hin, dass man sich auf die genannten Laufzeiten nicht verlassen soll. Versionen: Laut Versionsrichtlinie ist eine Version mindestens zwei Jahre nutzbar und läuft zwei Jahre nach dem Erscheinen der Nachfolgerin aus; Aufrufe gehen danach an die nächstältere verfügbare.
zweck: betrieb
Aus diesen Bausteinen wird kein eingehängter Kasten, sondern ein Bereich der Website. Der Newsroom zeigt die Beiträge als Karten oder Liste im Design der Seite, mit Datum, Auszug, eigenem Bild und einem Link zum Original. Eine Terminliste kann daneben stehen, sofern der Zugriff auf Veranstaltungen für das Projekt offensteht — sonst kommen die Termine aus dem CMS, was für die Auffindbarkeit ohnehin der bessere Ort ist.
Dazu kommt die Kuratierung: Weil die Beiträge als Datensätze im CMS liegen, kann die Redaktion einzelne verbergen, anpinnen oder ordnen, ohne auf Facebook etwas zu ändern. Und weil alles als echtes HTML im Dokument steht, ist es für Suchmaschinen lesbar — ergänzt um strukturierte Daten aus denselben Feldern.
Und der Bereich kostet fast nichts. Kein fremdes Skript, kein fremdes Stylesheet, keine fremden Schriften, Bilder in eigenen Formaten mit festen Maßen — das wirkt direkt auf die Core Web Vitals. Warum das mehr als Kosmetik ist, steht unter Performance im Stack.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, und er hat einen Kern: Die Beiträge werden serverseitig abgeholt und im CMS zwischengespeichert, das Frontend rendert sie als eigenes HTML. Ein geplanter Lauf ruft die Graph API auf, legt jeden Beitrag als Datensatz ab und schreibt die angehängten Bilder als eigene Dateien in die Medienverwaltung. Die Ausgabe liest danach ausschließlich aus diesem Bestand. Damit lädt kein Meta-Code im Browser des Besuchers, die Seite bleibt schnell — und der Bereich steht auch dann, wenn die Schnittstelle gerade nicht antwortet.
Das Zugriffstoken bleibt serverseitig: in der Konfiguration des Systems oder in einer Umgebungsvariablen, nie fest im Template und nicht im Repository. Der Erneuerungsweg wird mitgebaut, ebenso die Benachrichtigung, wenn mehrere Abrufe hintereinander scheitern. Und weil die Beiträge im CMS liegen, gehören sie der Website: Die Redaktion kann einzelne verbergen, anpinnen oder ordnen, ohne auf Facebook etwas zu ändern. Was sich zwischen den Systemen unterscheidet, sind nur die Bordmittel, mit denen wir das bauen.
// cms-01typo3
Wir bauen die Anbindung als eigene Extension. Der Abruf läuft als Scheduler-Task: Er fragt die Beiträge der Seite ab, gleicht sie gegen den vorhandenen Bestand ab und ergänzt nur, was neu ist. Die Beiträge werden Records mit eigenem TCA — Text, Zeitpunkt, Quell-ID, Link zum Original —, abgelegt in einem Systemordner und im Backend sichtbar wie jeder andere Inhalt. Die Bilder landen über die Dateiverwaltung im System und bekommen dort Alternativtexte. Das Zugriffstoken steht in der Extension-Konfiguration statt im Template. Im Frontend rendert ein Fluid-Template die Liste, ein Content-Element setzt die Redaktion auf jede Seite, die den Newsroom braucht.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so überlebt sie den Theme-Wechsel. Die Beiträge werden ein Custom Post Type mit Meta-Feldern für Zeitpunkt, Quell-ID und Ursprungslink, dazu eine Taxonomie, wenn nach Rubrik gefiltert werden soll. Der Abruf hängt an einem geplanten Lauf; für zuverlässige Zeitpunkte richten wir ihn über einen echten Cron des Servers ein statt über den Aufruf-getriebenen Standardweg. Bilder werden in die Mediathek importiert und erhalten dort ihre Größen. Das Token steht in der wp-config.php oder in einer Umgebungsvariablen. Fürs Frontend kommen ein Block für den Editor und Template-Teile dazu.
// cms-03statamic
Statamic läuft auf Laravel, und das macht diesen Teil angenehm gerade. Der Abruf wird ein Artisan-Command, den der Scheduler regelmäßig aufruft und der sich jederzeit von Hand nachziehen lässt. Die Beiträge werden Entries in einer eigenen Collection, beschrieben durch ein Blueprint mit Feldern für Text, Zeitpunkt, Quell-ID und Ursprungslink. Die Bilder gehen in einen Assets-Container und stehen damit für die Bildverarbeitung der Website bereit. Das Token steht in der .env und wird über die Konfiguration gelesen. Antlers oder Blade rendern die Liste — und weil Static Caching die Seiten ausliefert, kostet der Bereich beim Aufruf praktisch nichts.
// datenschutz
technik, nicht rechtsberatung
Der technische Sachverhalt ist schnell beschrieben: Ein eingebettetes Meta-Widget lädt Fremdcode nach und überträgt dabei Daten des Besuchers — mindestens seine IP-Adresse, weil ohne sie keine Auslieferung funktioniert. Das passiert beim Aufbau der Seite, also bevor der Besucher irgendetwas getan hat, und es passiert unabhängig davon, ob er den Feed am Ende überhaupt ansieht. Das ist keine Eigenheit von Meta, sondern gilt für jede Ressource von fremder Stelle. Der Unterschied liegt darin, wann das geschieht — und ob es überhaupt geschehen muss.
Bei einer Website, die wir trackingfrei bauen, muss es nicht. Genau deshalb ist der Weg bei siteway: serverseitig abholen, selbst rendern. Der Abruf geschieht einmal je Durchgang vom eigenen Server aus, nicht bei jedem Besuch aus jedem Browser. Beim Seitenaufruf wird dann überhaupt nichts von Meta geladen — kein Skript, kein Stylesheet, keine Schrift, kein Bild von fremder Domain. Die Frage nach der Einwilligung stellt sich an dieser Stelle nicht, weil es nichts gibt, wofür sie nötig wäre.
Soll aus einem konkreten Grund doch eingebettet werden, gilt dieselbe Regel wie bei jedem anderen Fremdinhalt: erst nach aktiver Einwilligung. Bis dahin steht an der Stelle ein beschrifteter Platzhalter, der benennt, was beim Laden passiert — nicht als Bildfläche getarnt, und die Entscheidung lässt sich zurücknehmen. Was dabei verarbeitet wird, halten wir als Dokumentation fest, damit sie nicht bei der ersten Rückfrage rekonstruiert werden muss.
Wir beschreiben hier die Technik und ihre Umsetzung — die rechtliche Bewertung des Einzelfalls gehört in die Hand von Juristinnen und Juristen. Was wir liefern, ist die Grundlage dafür: eine Umsetzung, die zeigt, wann welche Daten fließen. Wie das im Zusammenhang der ganzen Website aussieht, steht unter Sicherheit & Datenschutz; wer den Bestand einer vorhandenen Seite geprüft haben will, findet das im Datenschutz-Audit. Und weil eine Anbindung mit ablaufenden Token und alternden Versionen dauerhaft Aufmerksamkeit braucht, gehört sie in den Betrieb.
// faq
Die Graph API ist die HTTP-Schnittstelle, über die Anwendungen Daten der Meta-Plattform lesen und schreiben. Ihr Datenmodell besteht laut Dokumentation aus drei Bausteinen: Nodes sind einzelne Objekte mit eigener ID — eine Seite, ein Beitrag, ein Foto, ein Kommentar. Edges sind die Verbindungen zwischen ihnen, etwa von einer Seite zu ihren Beiträgen. Fields sind die Eigenschaften eines Objekts, die man gezielt anfordert. Für eine Website ist davon fast nur ein Ausschnitt interessant, nämlich der Page-Node und seine Verbindungen. Alles, was auf einer Facebook-Seite öffentlich sichtbar ist, ist damit im Prinzip auch maschinenlesbar abrufbar — vorausgesetzt, der Zugang ist eingerichtet und freigegeben.
Nicht über ein eingebettetes Widget, sondern über einen Umweg, der sich lohnt: Ein Dienst auf dem Server ruft die Graph API in festen Abständen auf, holt die Beiträge der Seite ab und legt sie im CMS ab — Text, Datum, Link zum Original, dazu das Bild als lokale Datei in der Medienverwaltung. Das Frontend liest danach nur noch aus dem eigenen Datenbestand und gibt eigenes HTML aus. Für den Besucher sieht das aus wie ein Feed, technisch ist es eine ganz normale Liste aus dem CMS. Das hat drei Folgen: Es lädt kein fremder Code im Browser, die Ausgabe fügt sich ins Design der Website ein statt in eine fremde Box, und die Beiträge stehen auch dann auf der Seite, wenn die Schnittstelle gerade nicht antwortet.
Alle drei, und das ist echter Projektaufwand, den man vorher einplanen sollte. Zuerst wird im Meta-Entwicklerbereich eine App angelegt, die den Zugriff überhaupt erst identifiziert. Dann wird ein Seiten-Zugriffstoken erzeugt: Es entsteht laut Dokumentation aus dem Tausch eines Nutzer-Tokens und ist jeweils an die Kombination aus Seite, Administrator und App gebunden. Dazu kommen die Berechtigungen, die genau beschreiben, was die App lesen darf — für das Auslesen einer Seite werden in der Referenz unter anderem pages_read_engagement und pages_read_user_content genannt, für öffentliche Seiteninhalte zusätzlich die Features Page Public Content Access und Page Public Metadata Access. Für den produktiven Einsatz führt der Weg über die App-Prüfung: Meta verlangt dafür eine Beschreibung des Anwendungsfalls samt Nachweisen. Das ist kein Nachmittag, sondern ein Vorgang mit Wartezeit — deshalb steht er bei uns am Anfang des Zeitplans und nicht am Ende.
Ja, aber nicht in der bequemen Variante. Ein eingebettetes Meta-Widget lädt Fremdcode nach und überträgt dabei Daten des Besuchers — mindestens seine IP-Adresse, weil ohne sie keine Auslieferung funktioniert — und zwar bevor er irgendetwas getan hat. Bei einer Website, die wir trackingfrei bauen, wäre das der einzige Fremdaufruf im Dokument. Deshalb ist der Standardweg: serverseitig abholen, selbst rendern. Dann verlässt beim Seitenaufruf kein Byte des Besuchers die eigene Infrastruktur, weil überhaupt nichts von Meta geladen wird. Soll aus einem konkreten Grund doch eingebettet werden, gilt dieselbe Regel wie bei jedem anderen Fremdinhalt: erst nach aktiver Einwilligung, davor ein beschrifteter Platzhalter. Die rechtliche Bewertung des Einzelfalls gehört in die Hand von Juristinnen und Juristen — wir liefern die technische Umsetzung und die Dokumentation, aus der hervorgeht, wann welche Daten fließen.
Technisch gibt es dafür den passenden Baustein: Der Event-Node führt in der Referenz Felder wie Name, Startzeit, Endzeit, Ort, Beschreibung und Titelbild — genau das, was eine Terminliste auf einer Website braucht. Der Zugriff ist allerdings der am engsten geregelte Teil dieser Schnittstelle; die Referenz weist ausdrücklich darauf hin, dass der Zugriff auf Events bei Nutzern und Seiten den Facebook-Marketing-Partnern vorbehalten ist. Wir prüfen deshalb vor dem Konzept, ob dieser Weg für ein Projekt offensteht, und benennen früh die Alternative: Die Termine werden im CMS gepflegt und stehen dort als eigener Inhalt mit strukturierten Daten — was für die Auffindbarkeit ohnehin der bessere Ort ist, weil Suchmaschinen den Termin dann direkt auf der Website finden.
Nichts, was der Besucher merkt. Weil das Frontend aus dem zwischengespeicherten Bestand im CMS rendert und nicht live abfragt, ist ein ausgefallener oder langsamer Abruf ein Betriebsvorfall und keine kaputte Seite: Der Bereich zeigt weiterhin den letzten erfolgreich geholten Stand. Der geplante Lauf protokolliert stattdessen den Fehler, versucht es beim nächsten Durchgang erneut und meldet sich, wenn mehrere Durchgänge hintereinander scheitern. Genau das ist der Grund, warum wir gar nicht erst live abfragen. Ein Feed, der bei jedem Seitenaufruf eine fremde Schnittstelle fragt, übernimmt deren Verfügbarkeit und deren Antwortzeit als eigene.
Ja — eine Anbindung ist kein Möbelstück, das man einmal hinstellt. Zwei Dinge altern planbar. Erstens die Zugriffstoken: Meta unterscheidet kurzlebige und langlebige Token, nennt in der Dokumentation Größenordnungen von wenigen Stunden beziehungsweise etwa zwei Monaten und weist zugleich darauf hin, dass man sich auf diese Laufzeiten nicht verlassen soll, weil sie sich ändern oder früher enden können. Ein Token braucht also einen definierten Erneuerungsweg, und der Ausfall braucht eine Benachrichtigung an einen Menschen. Zweitens die Schnittstelle selbst: Sie erscheint in Versionen mit Ablaufdatum. Laut Versionsrichtlinie ist jede Version mindestens zwei Jahre nutzbar und läuft zwei Jahre nach dem Erscheinen der Nachfolgeversion aus; Aufrufe an eine abgelaufene Version werden danach auf die nächstältere verfügbare weitergeleitet. Beides gehört in den laufenden Betrieb, nicht in die Projektphase.
Ja, in allen drei Systemen — und wir bauen die Anbindung jeweils selbst, mit den Bordmitteln des Systems. In TYPO3 entsteht eine eigene Extension: Der Abruf läuft als Scheduler-Task, die Beiträge werden Records mit eigenem TCA, Bilder landen in der Dateiverwaltung, das Zugriffstoken steht in der Extension-Konfiguration, im Frontend rendert ein Fluid-Template. In WordPress entsteht ein eigenes Plugin statt Theme-Code, damit die Anbindung den Theme-Wechsel überlebt: ein Custom Post Type für die Beiträge, ein geplanter Lauf für den Abruf, Bilder in der Mediathek, das Token in der wp-config.php oder in einer Umgebungsvariablen. In Statamic liegt Laravel darunter: ein Artisan-Command im Scheduler holt die Beiträge, sie werden Entries in einer eigenen Collection, Bilder gehen in einen Assets-Container, das Token steht in der .env. Die Mechanik ist überall dieselbe, nur die Bordmittel heißen anders.
// womit das zusammenhängt
baustein, kanäle & grundlagen
// komponente · buchen
Die Schnittstelle hier, der Baustein dort: Beiträge mehrerer Kanäle gebündelt auf der Website, kuratierbar und im eigenen Design — als buchbare Komponente.
zur komponente →
// stack · schnittstelle
Die Bild-Ebene desselben Hauses: Wie der Instagram-Feed auf die Website kommt — ebenfalls serverseitig geholt und selbst gerendert.
zur technik →
// stack · schnittstelle
Der berufliche Kanal: Unternehmensseite, Beiträge und was beim Zugang anders läuft als bei Meta.
zur technik →
// stack · grundlage
Wo Fremdcode ins Spiel kommt, wird es konkret: Einwilligung, Token serverseitig, Datensparsamkeit, Dokumentation.
zur technik →
// stack · grundlage
Kein Fremdskript, keine fremden Schriften, Bilder aus der eigenen Verwaltung: Warum der serverseitige Weg direkt auf die Core Web Vitals wirkt.
zur technik →
// leistung · buchen
Ablaufende Token, alternde Schnittstellenversionen, fehlgeschlagene Abrufe: Wer das im Blick behält und was dazugehört.
zur leistung →
Eine Anbindung ist selten die einzige: Wer Beiträge holt, holt später Termine, Bewertungen oder Produktdaten. Wie wir solche Vorhaben von der Analyse über das Mapping bis zu Monitoring und Betrieb führen, steht unter Schnittstellen & Integration.
// Facebook-Beiträge auf der Website — ohne Fremdcode im Browser?
Projekt anfragen