Du willst deine Blogbeiträge automatisch auf einer Facebook-Seite und einem Instagram-Konto veröffentlichen. Der Workflow steht, die Nodes sind konfiguriert, und dann scheitert alles an einem einzigen Feld: dem Zugriffstoken. Meta macht es einem an dieser Stelle bemerkenswert schwer, und die meisten Anleitungen im Netz überspringen genau die Punkte, an denen es tatsächlich klemmt.
Dieser Beitrag ist die Anleitung, die ich mir gewünscht hätte, als ich vor dem Problem saß. Sie beschreibt jeden Schritt mit der konkreten URL, den genauen Eingaben und – das ist der wichtigere Teil – den Prüfungen, mit denen du feststellst, ob es wirklich geklappt hat. Denn die Meta-Graph-API hat eine Eigenart, die dich stundenlang im Kreis laufen lässt, wenn du sie nicht kennst.
Drei Token, und nur eines ist das richtige
Der häufigste Fehler passiert, bevor man überhaupt anfängt: Man denkt, es gäbe „das Facebook-Token“. Es gibt drei, und sie bauen aufeinander auf.
Ein Nutzer-Token identifiziert dich als Person. Du bekommst es im Graph-API-Explorer mit einem Klick. Es lebt ein bis zwei Stunden. Für eine Automatisierung ist es damit vollkommen unbrauchbar – aber es ist der Ausgangspunkt.
Ein langlebiges Nutzer-Token entsteht, wenn du das kurzlebige gegen ein neues eintauschst. Es gilt 60 Tage. Auch das ist noch nicht das Ziel.
Ein Seiten-Token identifiziert nicht dich, sondern deine Facebook-Seite. Und hier kommt der entscheidende Punkt: Leitest du es aus einem langlebigen Nutzer-Token ab, läuft es überhaupt nicht ab. Leitest du es aus einem kurzlebigen ab, erbt es dessen Restlaufzeit von anderthalb Stunden.
Diesen Unterschied sieht man dem Token nicht an. Beide sehen aus wie eine 200 Zeichen lange Buchstabensuppe, beide funktionieren im ersten Test. Der eine ist am nächsten Morgen tot.
Ein Instagram-Token gibt es übrigens nicht. Instagram wird über dasselbe Seiten-Token angesprochen. Das setzt allerdings zwei Dinge voraus, die man vorher erledigt haben muss.
Bevor du anfängst: zwei Voraussetzungen
Erstens muss das Instagram-Konto ein Business-Konto sein. In der App: Profil, dann Menü, dann Konto und Sicherheit, dann Kontotyp und Tools, dann Zu professionellem Konto wechseln und dort Unternehmen wählen. Ein Creator-Konto reicht für das automatische Veröffentlichen nicht zuverlässig, ein privates gar nicht.
Zweitens muss dieses Konto mit der Facebook-Seite verknüpft sein. Der verlässliche Weg führt über die Meta Business Suite unter business.facebook.com/settings/instagram-account-v2, nicht über die Instagram-App. Dort wählst du das Konto aus und ordnest es der Seite zu.
Warum diese Reihenfolge wichtig ist: Verknüpfst du erst nachdem du das Token erzeugt hast, weiß das Token nichts davon. Berechtigungen und Zuordnungen werden beim Ausstellen eingefroren.
Schritt 1: Nutzer-Token mit den richtigen Berechtigungen
Der Graph-API-Explorer liegt unter developers.facebook.com/tools/explorer/. Wähle rechts oben deine Meta-App aus, stelle darunter Nutzer-Token ein und klicke auf Berechtigungen hinzufügen.
Fünf Berechtigungen brauchst du:
pages_show_list
pages_read_engagement
pages_manage_posts
instagram_basic
instagram_content_publish
Dann auf Zugriffsschlüssel generieren. Es öffnet sich ein Anmeldedialog – und hier passiert der Fehler, der mich am längsten aufgehalten hat: Du musst die Seite in diesem Dialog ausdrücklich anhaken. Klickst du zu schnell durch, bekommst du ein Token mit allen fünf Berechtigungen, das trotzdem keine einzige Seite sieht.
Prüfe es sofort. Trage im Explorer unten me/permissions ein und drücke Senden. Alle fünf müssen mit "status": "granted" erscheinen.
Schritt 2: Der Tausch gegen ein langlebiges Token
Im Access Token Tool gibt es eine Schaltfläche Verlängern. Bei neueren App-Typen fehlt sie – ohne Erklärung, ohne Hinweis. Der Weg über die API funktioniert dagegen immer, kostet aber den App-Geheimcode.
Den findest du in deinen App-Einstellungen unter Einstellungen → Allgemein, Feld App-Geheimcode, hinter einem Anzeigen-Knopf und einer Passwortabfrage.
Behandle diesen Wert wie einen Hauptschlüssel. Mit ihm lassen sich beliebig neue Tokens erzeugen. Er gehört nicht in Chats, nicht in Tickets und schon gar nicht in ein Repository.
Dann rufst du diese URL im Browser auf, mit deinen Werten anstelle der Platzhalter:
https://graph.facebook.com/v23.0/oauth/access_token
?grant_type=fb_exchange_token
&client_id=DEINE_APP_ID
&client_secret=DEIN_APP_SECRET
&fb_exchange_token=DEIN_NUTZER_TOKEN
Alles in eine Zeile, ohne Umbrüche. Die Antwort ist knapp:
{
"access_token": "EAA...",
"token_type": "bearer",
"expires_in": 5184000
}
5.184.000 Sekunden sind 60 Tage. Das ist dein langlebiges Nutzer-Token.
Schritt 3: Seiten-Token und Instagram-ID in einem Aufruf
Jetzt der Schritt, der zwei Probleme auf einmal löst:
https://graph.facebook.com/v23.0/DEINE_SEITEN_ID
?fields=access_token,instagram_business_account
&access_token=DEIN_LANGLEBIGES_NUTZER_TOKEN
Die Antwort enthält beides:
{
"id": "740198...",
"access_token": "EAA...",
"instagram_business_account": {
"id": "178414..."
}
}
Das access_token ist dein Seiten-Token – das kommt in n8n. Und die instagram_business_account.id ist genau die Zahl, die in die Instagram-Nodes gehört.
Interessant ist ein Nebenbefund: Bei mir lieferte GET /me/accounts eine leere Liste, obwohl pages_show_list erteilt war. Der direkte Zugriff über die Seiten-ID funktionierte dagegen tadellos. Eine leere Seitenliste ist also kein Beweis für fehlenden Zugriff – probiere immer auch den direkten Weg.
Schritt 4: Die Prüfung, die man nicht überspringen darf
Jetzt kommt der Teil, den ich am Anfang falsch gemacht habe.
Das Access Token Tool zeigt dir prominent an, wann das Token abläuft. Bei mir stand dort „läuft in etwa 3 Monaten ab“. Ich habe das geglaubt. Tatsächlich war das Token in anderthalb Stunden tot.
Der Grund: Die Oberfläche zeigt data_access_expires_at – die 90-Tage-Frist für den Datenzugriff. Das ist nicht die Gültigkeit des Tokens. Die steht in einem anderen Feld.
Frag also nach:
https://graph.facebook.com/v23.0/debug_token
?input_token=DEIN_SEITEN_TOKEN
&access_token=DEIN_LANGLEBIGES_NUTZER_TOKEN
Worauf es ankommt:
| Feld | Sollwert | Bedeutung |
|---|---|---|
type | PAGE | es ist wirklich ein Seiten-Token |
is_valid | true | gültig |
expires_at | 0 | läuft nie ab |
data_access_expires_at | Datum in ~90 Tagen | Datenzugriffsfrist, nicht die Gültigkeit |
scopes | alle fünf | Berechtigungen vollständig |
Steht bei expires_at eine Zahl statt der Null, hast du irgendwo das kurzlebige Nutzer-Token verwendet. Zurück zu Schritt 2.
Die Eigenart, die dich sonst im Kreis laufen lässt
Und jetzt zu dem Verhalten, das mich am meisten Zeit gekostet hat – und das in keiner Anleitung steht, die ich gefunden habe.
Die Graph-API antwortet auf ein gültiges Feld, für das dir die Berechtigung fehlt, nicht mit einem Fehler. Sie lässt das Feld einfach weg.
Konkret: Du fragst die Seite nach instagram_business_account. Zurück kommt ein sauberes, fehlerfreies JSON – nur ohne dieses Feld. Was heißt das jetzt? Entweder ist kein Instagram-Konto verknüpft. Oder es ist eines verknüpft, aber dein Token darf es nicht sehen. Die Antwort ist in beiden Fällen identisch.
Ich habe daraufhin dreimal die Verknüpfung im Meta-Konto neu gesetzt und dreimal dasselbe Ergebnis gemessen. Die Verknüpfung war nie das Problem.
Der Trick, mit dem sich die beiden Fälle unterscheiden lassen, ist eine Kontrollprobe: Frage ein Feld mit ab, das es garantiert nicht gibt.
GET /DEINE_SEITEN_ID?fields=instagram_business_account,dieses_feld_gibt_es_nicht
Kommt jetzt der Fehler (#100) Tried accessing nonexisting field, weißt du: Die API meldet ungültige Felder zuverlässig. Wenn instagram_business_account trotzdem stillschweigend fehlt, kann es nicht an einem Tippfehler liegen – dann fehlt die Berechtigung.
Das ist eine simple Technik, aber sie verwandelt eine mehrdeutige leere Antwort in einen belastbaren Befund. Ich benutze sie inzwischen bei jeder Graph-API-Fehlersuche.
Die zweite Falle: das Schattenkonto
Noch ein Fallstrick, über den ich gestolpert bin. Fragst du die Seite nach page_backed_instagram_accounts, bekommst du womöglich eine ID zurück, die genau aussieht wie ein Instagram-Konto – gleiche Länge, gleicher Zahlenaufbau.
Es ist keines. Es ist ein von Facebook automatisch erzeugtes Schattenkonto für Werbeanzeigen. Zum organischen Veröffentlichen taugt es nicht, und wenn du es in deine Workflow-Nodes einträgst, suchst du den Fehler an der völlig falschen Stelle.
Das echte Konto steht ausschließlich unter instagram_business_account.
In n8n eintragen – aber bitte vorsichtig
Ein Rat aus Erfahrung: Lege eine zweite Credential an, statt die funktionierende zu überschreiben.
Wenn dein bisheriges Token Facebook-Posts absetzen kann und dem neuen eine Berechtigung fehlt, hast du sonst mit einem Handgriff beides kaputtgemacht. Also: neue Credential vom Typ Facebook Graph API anlegen, das Seiten-Token eintragen, in den Nodes umstellen, erst Facebook testen, dann Instagram. Läuft beides, kannst du die alte löschen.
Instagram testen, ohne etwas zu veröffentlichen
Zum Schluss ein Kniff, der einem einen peinlichen Testpost erspart.
Instagram veröffentlicht in zwei Schritten: Erst legst du einen Media-Container an, dann publizierst du ihn. Der erste Schritt allein erzeugt nichts Sichtbares – der Container bleibt unsichtbar und verfällt nach 24 Stunden von selbst.
POST https://graph.facebook.com/v23.0/DEINE_IG_ID/media
?image_url=<oeffentlich erreichbare JPEG-URL>
&caption=Test
&access_token=DEIN_SEITEN_TOKEN
Kommt eine id zurück, funktioniert die gesamte Kette: Berechtigungen, Kontoverknüpfung, Bildannahme. Nur der letzte Aufruf media_publish fehlt noch – und den machst du dann im echten Betrieb.
Apropos Bild: Instagram nimmt beim Content Publishing keine Binärdaten entgegen, sondern verlangt eine öffentlich erreichbare JPEG-URL. Wenn dein WordPress die Beitragsbilder als WebP ausliefert – und das tun inzwischen viele –, musst du vorher umwandeln. Facebook akzeptiert WebP bei Foto-Uploads übrigens auch nicht.
Was tun, wenn es doch ausfällt
Ein dauerhaftes Seiten-Token kann trotzdem ungültig werden: wenn du dein Facebook-Passwort änderst, wenn du der App die Berechtigungen entziehst, wenn Meta ungewöhnliche Aktivität sieht oder wenn deine Administratorrechte an der Seite enden.
Dann wiederholst du die Schritte 1 bis 3. Deshalb lohnt es sich, im Workflow einen Fehlerpfad einzubauen, der dir eine E-Mail schickt und den betroffenen Eintrag zum Nachholen stehen lässt, statt ihn zu verlieren.
Die Kurzfassung
- Instagram auf Business umstellen und mit der Seite verknüpfen – vorher
- Explorer: Nutzer-Token mit fünf Berechtigungen, Seite im Dialog anhaken
me/permissionsgegenprüfen- App-Geheimcode holen
oauth/access_token?grant_type=fb_exchange_token…→ langlebiges Nutzer-TokenGET /{seiten-id}?fields=access_token,instagram_business_account→ Seiten-Token und IG-IDdebug_token→expires_atmuss0sein- Neue Credential in n8n, Facebook testen, dann Instagram
Acht Schritte, von denen sechs in fünf Minuten erledigt sind. Die Zeit geht für die zwei drauf, bei denen man nicht merkt, dass man sie falsch gemacht hat. Wenn du me/permissions und debug_token konsequent abfragst, statt der Oberfläche zu glauben, ersparst du dir den Rest.
Was danach kommt – wie aus dem Token eine laufende Automatisierung wird, die Blogbeiträge selbstständig auf Facebook und Instagram veröffentlicht –, beschreibt die Serie Hands-on-Lab: Social-Media-Automatisierung mit n8n. Der zweistufige Instagram-Weg und die Bildformate stehen in Teil 4. Was Social-Media-Kanäle für einen Blog überhaupt bedeuten, habe ich in Die Bedeutung von Social Signals für dein Blog aufgeschrieben.

Schreibe einen Kommentar