// stack · schnittstelle
Der Instagram-Feed auf der eigenen Website ist einer der meistgewünschten Bausteine — und einer der wenigen, bei denen der übliche Weg der schlechteste ist. Ein eingebettetes Widget bringt Fremdcode in die Seite und überträgt Besucherdaten. siteway holt die Beiträge stattdessen serverseitig ab und rendert sie selbst. Diese Seite beschreibt die Schnittstelle dahinter: was sie liefert, was der Zugang kostet an Betrieb, und wie der Feed ins CMS kommt.
// definition
Die Instagram Platform ist die Entwicklerschnittstelle, über die sich die Beiträge eines Instagram-Kontos programmatisch auslesen lassen. Kein Widget, kein Baukasten, keine Darstellung — eine Datenquelle. Sie antwortet auf eine Anfrage mit einer Liste von Beiträgen, und was daraus auf einer Website entsteht, entscheidet die Website.
Zu einem einzelnen Beitrag sind laut Dokumentation unter anderem eine Kennung, die Bildunterschrift, der Medientyp, die Medien-URL, bei Videos ein Vorschaubild, der Permalink zum Original, ein Zeitstempel, der Benutzername und ein Alternativtext verfügbar. Als Medientyp nennt die Dokumentation IMAGE, VIDEO und CAROUSEL_ALBUM — ein Album besteht also aus mehreren Einzelmedien, die getrennt abgeholt werden, wenn mehr als das erste Bild erscheinen soll.
Der Zugang ist an Bedingungen geknüpft: Die Schnittstelle richtet sich an Instagram-Konten von Unternehmen und Creatorn, nicht an private Profile. Dazu kommen eine App im Entwicklerbereich und ein Zugriffstoken. Wie daraus ein Bereich auf der Website wird, beschreiben die Komponenten Social Media Newsroom und Portfolio & Media Galerie. Hier geht es um die Schnittstelle darunter. Die Facebook-Ebene desselben Hauses steht unter Meta.
// praxis
abruf auf dem server
Die erste Entscheidung fällt vor dem Design: Der Abruf läuft auf dem Server, nicht im Browser. Ein geplanter Lauf spricht die Schnittstelle in ruhigem Takt an, holt die letzten Beiträge und schreibt sie weg. Der Browser des Besuchers sieht davon nichts — er bekommt fertiges HTML von der eigenen Domain, so wie bei jedem anderen Inhalt der Seite auch.
Die zweite Entscheidung betrifft die Bilder. Sie werden nicht verlinkt, sondern heruntergeladen und in der Dateiverwaltung des CMS abgelegt. Von dort aus laufen sie durch dieselbe Bildpipeline wie alle anderen Motive: mehrere Größen, AVIF und WebP, feste Seitenverhältnisse, verzögertes Laden. Ein Instagram-Bild in Originalgröße wäre für eine Kachel im Raster deutlich zu groß — nach der Pipeline ist es das nicht mehr.
Die dritte Entscheidung ist die Datenhaltung. Beiträge werden Datensätze im CMS — Bild, Bildunterschrift, Zeitstempel, Permalink, Medientyp. Damit sind sie sichtbar, durchsuchbar und im Zweifel korrigierbar: Ein Beitrag lässt sich ausblenden, eine Bildunterschrift kürzen, ein Alternativtext ergänzen, wenn die Schnittstelle keinen mitliefert. Und weil die Daten liegen, statt bei jedem Aufruf geholt zu werden, bleibt der Feed sichtbar, wenn die Schnittstelle nicht antwortet.
Der Zugriffstoken bleibt dabei auf dem Server. Er steht in der Konfiguration des Systems oder in einer Umgebungsvariablen, nie im Template und nie im Quelltext der Seite. Weil er eine begrenzte Gültigkeit hat, gehört seine Erneuerung in den Betrieb — automatisiert, mit Log und Meldung, wenn ein Lauf fehlschlägt.
Und schließlich das Frontend: eigenes Markup, eigenes Design. Der Feed sieht aus wie die Website und nicht wie ein Fremdkörper, die Kacheln haben feste Seitenverhältnisse, die Bildunterschrift ist echter Text, und der Permalink führt zum Original. Wie derselbe Mechanismus für mehrere Kanäle gleichzeitig aussieht, steht bei der Komponente Social Media Newsroom.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Entwicklerdokumentation zur Instagram-Plattform — Feldnamen und Zugangsbedingungen im Original. Versionsnummern und Kontingente ändern sich und stehen deshalb nicht auf dieser Seite; sie gehören in die Umsetzung eines konkreten Projekts, nicht in eine Technikbeschreibung.
// d-01beiträge
Die Schnittstelle gibt die Medien des eigenen Kontos zurück. Dokumentiert sind unter anderem Kennung, Bildunterschrift, Medien-URL, Permalink, Zeitstempel und Benutzername. Genug für einen vollständigen Feed — Bild, Text, Datum, Link zum Original.
zweck: datenquelle
// d-02medientypen
Als Medientyp nennt die Dokumentation IMAGE, VIDEO und CAROUSEL_ALBUM; zu Videos kommt ein Vorschaubild. Für die Darstellung heißt das drei Fälle statt einem — ein Album besteht aus mehreren Einzelmedien und braucht einen eigenen Abruf.
zweck: darstellung
// d-03zugang
Voraussetzung ist ein Instagram-Konto vom Typ Unternehmen oder Creator — private Profile bleiben außen vor. Dazu kommt eine App im Entwicklerbereich, über die der Zugriff läuft. Diesen Teil richten wir gemeinsam mit dem Kunden ein, weil die Konten ihm gehören.
zweck: voraussetzung
// d-04token
Die Dokumentation unterscheidet kurzlebige und langlebige Token; beide haben eine begrenzte Gültigkeit, der langlebige muss vor Ablauf verlängert werden. Das Token liegt bei uns serverseitig in der Konfiguration — nie im Template, nie im Quelltext der Seite.
zweck: authentifizierung
// d-05bilder
Der Abruf lädt die Medien herunter und legt sie in der Dateiverwaltung ab. Danach gilt für sie dieselbe Pipeline wie für jedes andere Motiv: mehrere Größen, moderne Formate, festes Seitenverhältnis, verzögertes Laden — ausgeliefert von der eigenen Domain.
zweck: eigene kopie
// d-06betrieb
Antwortet die Schnittstelle nicht, bleibt der letzte Stand stehen — die Seite hat keine Lücke. Ein fehlgeschlagener Lauf landet im Log und meldet sich. Ein leerer Feed ist fast immer ein abgelaufenes Token, und das ist ein Betriebsthema, kein Einbaufehler.
Aus den abgeholten Datensätzen wird ein Raster aus Kacheln, das zum Design der Seite gehört: gleiche Abstände, gleiche Ecken, gleiche Typografie wie überall sonst. Jede Kachel zeigt Bild, Datum und den Anfang der Bildunterschrift; ein Klick öffnet entweder eine Detailansicht auf der eigenen Seite oder den Permalink zum Beitrag auf Instagram — je nachdem, wohin die Besucher gehen sollen.
Weil der Feed echtes HTML ist, ist er auch bedienbar und lesbar: Die Bildunterschrift ist Text und kein Bildinhalt, die Kacheln sind per Tastatur erreichbar, jedes Bild hat einen Alternativtext — den aus der Schnittstelle, wenn einer kommt, sonst einen aus der Redaktion. Mehr dazu steht unter Barrierefreiheit im Stack.
Und das Raster steht von Anfang an. Jede Kachel hat ein festes Seitenverhältnis, die Bilder werden mit Breiten- und Höhenangabe ausgeliefert, nichts rutscht nach. Warum das mehr als Kosmetik ist, steht unter Performance im Stack — und wie derselbe Umgang mit vielen Bildern als eigener Baustein aussieht, bei der Portfolio & Media Galerie.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, und er beginnt mit einer Regel: Die Beiträge werden serverseitig abgeholt, die Bilder heruntergeladen und im CMS abgelegt. Ein geplanter Lauf spricht die Schnittstelle an, schreibt Bildunterschrift, Zeitstempel, Medientyp und Permalink in Datensätze und legt die Medien in der Dateiverwaltung ab. Das Frontend rendert daraus einen eigenen Feed — eigenes Markup, eigenes Design. Damit lädt kein Instagram-Code im Browser des Besuchers, und die Bilder kommen in modernen Formaten wie AVIF und WebP von der eigenen Domain statt in Originalgröße von fremder Stelle.
Der zweite Teil der Regel betrifft den Betrieb. Der Zugriffstoken bleibt serverseitig — in der Konfiguration des Systems oder in einer Umgebungsvariablen, nie im Template. Weil er eine begrenzte Gültigkeit hat, gehört seine Erneuerung in denselben automatisierten Lauf wie der Abruf. Und weil die Beiträge im CMS liegen, bleibt der Feed sichtbar, wenn die Schnittstelle einmal nicht antwortet: Die Seite zeigt den letzten Stand, statt eine Lücke zu hinterlassen. 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 spricht die Schnittstelle an, legt neue Beiträge als Records mit eigenem TCA an — Bildunterschrift, Zeitstempel, Medientyp, Permalink — und lädt die Bilder in die Dateiverwaltung, wo sie als reguläre Dateireferenzen an den Records hängen und durch die übliche Bildverarbeitung laufen. Der Zugriffstoken steht in der Extension-Konfiguration statt im Template, seine Erneuerung hängt am selben Task. Im Frontend rendert ein Fluid-Template das Kachelraster; ein Content-Element setzt die Redaktion auf jede Seite, die den Feed zeigen soll.
// 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 Permalink, Medientyp und Zeitstempel, die Bildunterschrift landet im Inhalt. Ein geplanter Lauf holt neue Beiträge ab, lädt die Medien in die Mediathek und hängt sie als Beitragsbild an, sodass die Größenvarianten automatisch entstehen. Der Zugriffstoken steht in der wp-config.php oder in einer Umgebungsvariablen. Fürs Frontend kommen ein Block für den Editor und Template-Teile dazu, die das Raster ausgeben.
// cms-03statamic
Statamic läuft auf Laravel, und das macht diesen Teil angenehm gerade. Wir schreiben einen Artisan-Command für den Abruf, den der Laravel-Scheduler regelmäßig aufruft und der auch von Hand nachlaufen kann. Er legt die Beiträge als Entries in einer eigenen Collection an — beschrieben über einen Blueprint mit Feldern für Bildunterschrift, Zeitstempel, Medientyp und Permalink — und speichert die Bilder in einem Assets-Container, aus dem die Größenvarianten erzeugt werden. Der Zugriffstoken steht in der .env und wird über die Konfiguration gelesen. Antlers oder Blade rendern das Raster, Static Caching liefert es aus.
// datenschutz
technik, nicht rechtsberatung
Der technische Sachverhalt ist schnell beschrieben: Ein eingebettetes Instagram-Widget lädt Skript, Schriften und Bilder von fremden Servern. Damit diese Auslieferung überhaupt funktionieren kann, geht die IP-Adresse des Besuchers dorthin; in der Regel kommen Cookies und Wiedererkennungsmerkmale dazu. Das ist keine Eigenheit von Instagram, sondern gilt für jede Ressource, die von fremder Stelle geladen wird — der Unterschied liegt darin, ob das ungefragt beim Seitenaufruf passiert.
Bei einer Website, die wir trackingfrei bauen, wäre ein automatisch mitladender Feed der einzige Fremdaufruf im Dokument — und damit die Ausnahme von der eigenen Regel. Deshalb ist der serverseitige Abruf bei siteway der Standardweg: Die Beiträge liegen als eigene Kopien im CMS, die Bilder kommen von der eigenen Domain, und beim Seitenaufruf fließen keine Besucherdaten an Instagram. Wer eine echte Einbettung braucht — etwa weil ein einzelner Beitrag im Original erscheinen soll —, bekommt sie hinter einer Einwilligung, mit beschriftetem Schalter und einem Platzhalter davor.
Dazu gehört ein zweiter Punkt, der oft übersehen wird: die Rechte an den Bildern. Ein Feed, wie wir ihn bauen, zeigt die Beiträge des eigenen Kontos — an denen hat der Betreiber die Rechte in der Regel selbst. Sobald fremde Beiträge dazukommen, etwa Gästefotos unter einem Hashtag, ist das eine andere Frage: Fremde Bilder zu vervielfältigen setzt eine Erlaubnis voraus, und abgebildete Personen haben eigene Rechte am Bild. Die Schnittstelle kennt diesen Unterschied nicht — deshalb bauen wir bei kuratierten Feeds eine Freigabe im CMS ein, damit nichts ungeprüft erscheint.
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, und eine Dokumentation dazu. 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.
// faq
Die Instagram Platform ist die Entwicklerschnittstelle, über die sich die Beiträge eines Instagram-Kontos programmatisch auslesen lassen — also ohne dass jemand sie von Hand in die Website kopiert. Sie richtet sich laut Dokumentation an Instagram-Konten von Unternehmen und Creatorn, nicht an private Profile. Zu einem Beitrag liefert sie unter anderem die Bildunterschrift, den Medientyp, die Medien-URL, bei Videos ein Vorschaubild, den Permalink zum Original, einen Zeitstempel und einen Alternativtext. Mehr steckt nicht dahinter: Es ist eine Datenquelle, kein fertiger Baustein. Was daraus auf der Seite entsteht, entscheidet die Website.
Der Weg, den wir gehen, läuft in drei Schritten. Erstens holt ein geplanter Lauf auf dem Server die letzten Beiträge über die Schnittstelle ab. Zweitens lädt derselbe Lauf die Bilder herunter und legt sie in der Dateiverwaltung des CMS ab, zusammen mit Bildunterschrift, Zeitstempel und Permalink als ganz normale Datensätze. Drittens rendert das Frontend daraus einen eigenen Feed — eigenes Markup, eigenes Design, eigene Bildgrößen. Der Browser des Besuchers spricht dabei nie mit Instagram. Der Unterschied zum eingebetteten Widget ist damit nicht kosmetisch, sondern grundsätzlich: Die Website zeigt eigene Kopien statt fremder Einbettungen.
Das hängt daran, wie er gebaut ist. Ein eingebettetes Instagram-Widget lädt Skript, Schriften und Bilder von fremden Servern; damit diese Auslieferung überhaupt funktionieren kann, geht die IP-Adresse des Besuchers dorthin, und in der Regel kommen Cookies und Wiedererkennungsmerkmale dazu. Bei einer trackingfrei gebauten Website ist das der einzige Fremdaufruf im Dokument — und damit die Ausnahme von der eigenen Regel. Deshalb holen wir die Beiträge serverseitig und rendern sie selbst: Dann fließen beim Seitenaufruf keine Besucherdaten an Instagram. Wer trotzdem eine echte Einbettung will, bekommt sie hinter einer Einwilligung. Die rechtliche Bewertung des Einzelfalls gehört in die Hand von Juristinnen und Juristen; wir liefern die technische Umsetzung und die Dokumentation dazu.
Weil der Zugriffstoken abgelaufen ist. Die Instagram-Dokumentation unterscheidet kurzlebige und langlebige Token; beide haben eine begrenzte Gültigkeit, und der langlebige muss vor seinem Ablauf verlängert werden. Passiert das nicht, antwortet die Schnittstelle irgendwann mit einem Fehler statt mit Beiträgen — und ein Feed, der sich nur auf den Live-Abruf verlässt, ist von einem Tag auf den anderen leer. Wir behandeln das als Betriebsthema, nicht als Einmalaufgabe: Die Erneuerung läuft automatisiert, der Abruf schreibt in ein Log, ein fehlgeschlagener Lauf meldet sich, und weil die Beiträge im CMS liegen, bleibt der Feed sichtbar, bis das Token wieder stimmt. Genau dafür gibt es Betrieb, Wartung und Support.
Dokumentiert sind unter anderem eine Kennung, die Bildunterschrift, der Medientyp, die Medien-URL, bei Videos ein Vorschaubild, der Permalink zum Beitrag auf Instagram, ein Zeitstempel, der Benutzername und ein Alternativtext. Als Medientyp nennt die Dokumentation IMAGE, VIDEO und CAROUSEL_ALBUM — ein Album besteht also aus mehreren Einzelmedien, die getrennt abgeholt werden müssen, wenn mehr als das erste Bild gezeigt werden soll. Aus diesen Feldern lässt sich ein vollständiger Feed bauen: Bild, Text, Datum und ein Link zum Original. Was die Schnittstelle nicht liefert, erfinden wir nicht dazu.
Ein Feed, wie wir ihn bauen, zeigt die Beiträge des eigenen Kontos — an denen hat der Betreiber die Rechte in der Regel selbst. Sobald fremde Beiträge dazukommen, etwa Bilder von Gästen, Kundinnen oder Kooperationen unter einem Hashtag, ist das eine andere Frage: Fremde Fotos zu vervielfältigen setzt eine Erlaubnis voraus, und abgebildete Personen haben eigene Rechte am Bild. Wir sagen das offen, weil die Technik den Unterschied nicht kennt — für die Schnittstelle sieht beides gleich aus. Deshalb bauen wir bei kuratierten Feeds eine Freigabe im CMS ein, damit nichts ungeprüft erscheint. Eine Rechtsberatung ist das nicht; die gehört in fachkundige Hände.
Ein eingebettetes Widget schon: Es bringt fremdes JavaScript, eigene Schriften und Bilder in Originalgröße mit, arbeitet im Hauptthread und baut sich erst nach dem Laden auf, wodurch das Layout nachträglich verspringen kann. Ein selbst gerenderter Feed hat davon nichts. Die Bilder liegen als AVIF und WebP in mehreren Größen auf der eigenen Domain, werden mit festen Seitenverhältnissen ausgeliefert und laden verzögert, sobald sie in die Nähe des sichtbaren Bereichs kommen. Das Markup ist Teil der Seite und braucht kein zusätzliches Skript. Der Feed kostet damit ungefähr so viel wie eine Bildergalerie — und nicht so viel wie eine fremde Anwendung in der Seite.
Ja, in allen drei Systemen — und wir bauen die Einbindung jeweils selbst, mit den Bordmitteln des Systems. In TYPO3 entsteht eine eigene Extension: der Abruf als Scheduler-Task, die Beiträge als Records, die Bilder in der Dateiverwaltung, der Zugriffstoken in der Extension-Konfiguration, im Frontend ein Fluid-Template. In WordPress entsteht ein eigenes Plugin statt Theme-Code: ein Custom Post Type für die Beiträge, ein geplanter Lauf für den Abruf, die 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, die Beiträge als Entries in einer eigenen Collection, die Bilder in einem Assets-Container, das Token in der .env. Die Mechanik ist überall dieselbe, nur die Bordmittel heißen anders.
// womit das zusammenhängt
baustein, technik & grundlagen
// komponente · buchen
Die Schnittstelle hier, der Baustein dort: mehrere Kanäle gebündelt, kuratiert und im eigenen Design als buchbare Komponente.
zur komponente →
// komponente · buchen
Viele Bilder, trotzdem schnell: Raster, Lightbox, Filter und Pflege im CMS — der Baustein für alles Visuelle.
zur komponente →
// stack · schnittstelle
Dasselbe Haus, andere Ebene: die Facebook-Seite der Schnittstelle — Seiten, Beiträge und was davon auf die Website gehört.
zur technik →
// stack · grundlage
Wo Fremdcode ins Spiel kommt, wird es konkret: Einwilligung, Token serverseitig, Datensparsamkeit, Dokumentation.
zur technik →
// stack · grundlage
Eigene Bilder in modernen Formaten, festes Raster, kein fremdes Skript — das wirkt direkt auf die Core Web Vitals.
zur technik →
// leistung · buchen
Analyse, Mapping, Umsetzung, Monitoring und Betrieb einer Anbindung — als buchbare Leistung beschrieben.
zur leistung →
// Instagram-Feed ohne Fremdcode im Browser?
Projekt anfragen