Social-Media-Access-Tokens: Long-Lived, Refresh und warum sie ständig ablaufen

Dein Instagram Access Token läuft ab, weil Meta ihn für 60 Tage ausstellt und nur verlängert, wenn du darum bittest. Facebook, LinkedIn, TikTok, X und YouTube ticken jeweils nach einer anderen Uhr und mit einem anderen Refresh-Aufruf. Hier sind die echten Laufzeiten, nachgelesen am 12. Oktober 2026 in der Doku der jeweiligen Plattform, jeweils mit dem passenden Refresh-Request.

Was ein Instagram Access Token eigentlich ist

Den einen Instagram-Token gibt es nicht. Es gibt zwei Wege, und die laufen unterschiedlich ab.

Bei Instagram API with Instagram Login schickt deine App den Nutzer zu Instagram, bekommt einen Authorization Code zurück und tauscht ihn ein. Metas Business-Login-Dokumentation legt die Regeln fest: Der Authorization Code ist eine Stunde gültig und nur einmal verwendbar, du schickst ihn per POST an https://api.instagram.com/oauth/access_token mit grant_type=authorization_code und bekommst einen Short-lived Token. Diesen Short-lived Token speicherst du nicht. Du tauschst ihn serverseitig ein:

curl -s -G https://graph.instagram.com/access_token \
  -d grant_type=ig_exchange_token \
  -d client_secret=$IG_APP_SECRET \
  -d access_token=$SHORT_LIVED_TOKEN

Die Antwort enthält expires_in: 5183944, also 60 Tage minus ein paar Minuten. Das ist dein Long-lived Token.

Bei Instagram API with Facebook Login ist der Account mit einer Facebook Page verknüpft, und du arbeitest stattdessen mit einem Page Access Token. Gleiche Posting-Endpoints, anderer Token, andere Ablaufregeln. Entscheide dich pro App für einen Weg.

Langlebiger Access Token auf Instagram: die 60-Tage-Uhr und die 24-Stunden-Regel

Ein langlebiger Instagram-Token ist nicht dauerhaft. Er ist erneuerbar, und das ist ein anderes Versprechen. Du erneuerst ihn mit einem einzigen GET:

curl -s -G https://graph.instagram.com/refresh_access_token \
  -d grant_type=ig_refresh_token \
  -d access_token=$LONG_LIVED_TOKEN

Es gelten drei Bedingungen, alle drei von derselben Meta-Seite:

1. Der Token muss mindestens 24 Stunden alt sein. Ein Refresh direkt nach dem Austausch schlägt fehl.
2. Der Token darf nicht schon abgelaufen sein. Meta ist da eindeutig: Ein Token, der 60 Tage ohne Refresh bleibt, „kann nicht mehr erneuert werden“.
3. Der Nutzer muss deiner App weiterhin diese Berechtigung erteilt haben: instagram_business_basic.

An Bedingung 2 sterben die Accounts. Es gibt keine Gnadenfrist und keinen Aufruf, der den Token zurückholt. Sind die 60 Tage vorbei, führt der einzige Weg zurück über den kompletten Login-Flow, und das heißt, der Mensch muss noch einmal klicken. Der Refresh-Job ist also kein Nice-to-have, er hält die Integration am Leben. Ich lasse ihn im Takt von Tagen laufen, nicht von Wochen: Ein täglicher Durchlauf, der alles erneuert, was älter als 30 Tage ist, lässt dir 30 Tage Puffer für einen kaputten Cronjob, ein misslungenes Deployment oder einen Urlaub.

Facebook Page Access Token: der Token, der sich anders verhält

Ein Facebook-Page-Token wird abgeleitet, nicht direkt ausgestellt. Du loggst den Admin ein, bekommst einen User-Token und holst dir über die Graph API den Page-Token. Metas Leitfaden zu Access Tokens nennt für die User-Seite klare Zahlen: Kurzlebige User-Tokens "halten in der Regel etwa ein bis zwei Stunden", langlebige User-Tokens "halten etwa 60 Tage", und Apps mit Standard Access auf die Marketing API oder mit System-User-Tokens bekommen Tokens, die "nicht zeitbasiert ablaufen".

Für den Page-Token selbst nennt derselbe Leitfaden keine Lebensdauer. Dort steht, ein Page-Token sei "für jede Kombination aus Page, Admin und App eindeutig", und er verweist auf das Access Token Tool und die Doku zum Ablauf. Hardcode also keine Annahme. Prüf expires_at im Debugger für deine eigene App und speichere den Wert: Das Verhalten hängt davon ab, von welchem Token du ihn abgeleitet hast. Die oft wiederholte Behauptung, Page-Tokens würden nie ablaufen, stimmt nur für manche Ableitungen, und Meta warnt davor, sich auf eine veröffentlichte Lebensdauer zu verlassen.

Token-Laufzeiten auf sechs Plattformen

Jede Zahl unten stammt aus der Entwicklerdokumentation der jeweiligen Plattform, gelesen am 12. Oktober 2026. Wo eine Seite keine Zahl veröffentlicht, steht das so in der Zelle, statt zu raten.

Zwei Zeilen verdienen mehr als eine Zelle.

LinkedIns Seite zu Refresh Tokens sagt, dass programmatischer Refresh "für alle zugelassenen Partner der Marketing Developer Platform (MDP)" verfügbar ist. Gehört deine App nicht dazu, bekommst du einen 60-Tage-Access-Token und keinen Refresh Token, und das Mitglied muss die App von Hand neu autorisieren. Auch die Uhr des Refresh Tokens selbst wird nicht zurückgesetzt: LinkedIns Beispiel rechnet es durch, an Tag 1 noch 365 Tage, an Tag 59 noch 306, an Tag 360 nur noch 5. Ein Refresh bringt dir einen neuen Access Token, nie ein neues Jahr.

Googles OAuth-2.0-Seite listet auf, wann ein Refresh Token nicht mehr funktioniert, und was kleine Projekte erwischt, ist der Veröffentlichungsstatus: Eine externe App, die noch im Status Testing ist, bekommt Refresh Tokens, die "in 7 Tagen ablaufen". Außerdem gibt es ein Limit von 100 Refresh Tokens pro Google-Konto und Client-ID, und der 101. macht den ältesten stillschweigend ungültig. Wenn du bei jedem Lauf einen neuen Token erzeugst, statt einen wiederzuverwenden, stößt du genau darauf.

Access Token bei einer Social-API erneuern: das Muster, das funktioniert

Die Aufrufe unterscheiden sich, das Muster nicht. Vier Regeln gelten auf allen sechs Plattformen.

Speichere das Ablaufdatum, nicht nur den Token. Eine Zeile mit access_token, refresh_token, expires_at und refresh_expires_at lässt einen einzigen Cronjob eine einzige Frage stellen: Was läuft in den nächsten 7 Tagen ab? Ohne expires_at bleibt dir nur, auf einen 401 zu warten.

Erneuere den Token früh und nach festem Zeitplan. Refresh-on-401 scheitert genau auf der Plattform, auf der es nicht funktionieren kann: Instagram, wo ein abgelaufener Token nicht mehr zu retten ist. Wegen Instagrams Mindestalter von 24 Stunden kannst du außerdem nicht jederzeit auf Abruf erneuern.

Speichere immer, was zurückkommt. TikToks Refresh-Antwort kann einen neuen refresh_token mit einem neuen refresh_expires_in zurückgeben, und TikToks Doku zum Token-Management sagt, du sollst den neuen Wert verwenden, wenn er sich geändert hat. Eine Integration, die immer wieder den ursprünglichen Refresh Token schickt, funktioniert, bis sie es nicht mehr tut.

Behandle das erneute Verbinden als Produkt-Feature, nicht als Fehlerpfad. Tokens werden widerrufen, wenn der Nutzer sein Passwort ändert und Gmail-Scopes im Spiel sind, deine App entfernt oder die Firma verlässt, deren Page er verwaltet hat. Die Frage ist nicht, ob du das vermeidest, sondern wie schnell der Account-Inhaber davon erfährt. Die Token-Dokumentation von X erinnert daran, dass das schon bei der Autorisierung beginnt: Fehlt offline.access in den ursprünglichen Scopes, wird nie ein Refresh Token ausgegeben, und dann hilft nur ein neuer Consent-Screen.

Was ich stattdessen mache

Ich habe aufgehört, diese Schicht selbst zu schreiben. PlugKit verbindet Accounts mit einem einzigen Aufruf, GET /connect/{platform}?profileId=…, liefert eine authUrl, die du öffnest, und speichert und erneuert die Tokens selbst. Die Dokumentation zu Profilen und Accounts sagt ausdrücklich, dass Account-Antworten platform, username, status und profileId zurückgeben und nie den Access Token, und genau darum geht es: In meiner Datenbank liegt kein Token, der leaken kann oder dessen Erneuerung ich vergessen könnte.

Wichtiger als der Refresh ist das Fehlersignal. Zu den Webhooks von PlugKit gehört account.disconnected, das ausgelöst wird, wenn ein Account getrennt wird oder sein Token nicht mehr funktioniert. Genau dieses Event brauchst du, denn jedes Design oben endet trotzdem gleich: Ab und zu muss ein Mensch klicken, und dein Job ist, ihn noch am selben Tag zu fragen und nicht erst drei Wochen später, wenn die Posts längst still und leise ausgeblieben sind.

Wo PlugKit nicht die Antwort ist: Wenn du einen Account auf einer Plattform betreibst, ist der Refresh-Job oben 40 Zeilen lang und du brauchst uns nicht. Wenn du eine Plattform brauchst, die wir nicht unterstützen, schreibst du den OAuth-Flow sowieso selbst. Und die durchgereichten Kosten sind real: X-API-Aufrufe werden zum Selbstkostenpreis abgerechnet, $0.005 pro Read und $0.015 pro Publish, zusätzlich zum Plan.

Für alles, was auf diesen Tokens aufbaut, lies den Leitfaden zu Social-Media-APIs 2026 und den Leitfaden zur Instagram Graph API. Die Tabelle der Rate Limits ist die andere Hälfte des Problems. Wenn ein Agent das Posten übernimmt, ist MCP oder REST API für deinen Agenten die Entscheidung, die davor kommt.

PlugKit kostet $49 im Monat für 5 verbundene Accounts, jederzeit kündbar, oder $97 für 30. Die Testphase ist 7 Tage kostenlos, ohne Karte, mit einem verbundenen Account, und sie beginnt, sobald du diesen Account verbindest.

FAQ

Warum läuft mein Instagram Access Token immer wieder ab?

Weil ein langlebiger Instagram-Token 60 Tage hält und erneuerbar ist, nicht dauerhaft. Du musst refresh_access_token mit grant_type=ig_refresh_token aufrufen, bevor diese 60 Tage ablaufen. Der Token muss außerdem mindestens 24 Stunden alt sein, damit er sich erneuern lässt, und laut Metas Dokumentation kann er nach dem Ablauf nicht mehr erneuert werden, der User muss sich also neu einloggen.

Wie lange hält ein langlebiger Access Token auf Instagram?

60 Tage. Die Antwort auf den Exchange liefert expires_in: 5183944 Sekunden, und jeder erfolgreiche Refresh gibt dir ab diesem Moment weitere 60 Tage.

Läuft ein Facebook Page Access Token ab?

Metas Leitfaden zu Access Tokens für Facebook Login nennt keine Lebensdauer für Page-Tokens. Er bestätigt 1 bis 2 Stunden für kurzlebige User-Tokens und etwa 60 Tage für langlebige und verweist für Page- und App-Tokens auf das Access Token Tool. Prüf expires_at für deine eigene App, statt einem Blogpost zu glauben, auch diesem hier.

Kann ich bei jeder Social-Media-API einen Token erneuern?

Nein. TikTok, LinkedIn, Google und X nutzen alle Refresh Tokens, aber LinkedIn beschränkt den programmatischen Refresh auf zugelassene Partner der Marketing Developer Platform, und X stellt nur dann einen Refresh Token aus, wenn die ursprüngliche Autorisierung den Scope offline.access angefordert hat. Wo kein Refresh möglich ist, bleibt nur eine neue Autorisierung durch den Inhaber des Accounts.

Was passiert mit geplanten Posts, wenn ein Token stirbt?

Geplante Posts scheitern beim Veröffentlichen, meist mit einem 401 der Plattform, und in den meisten Stacks erfährt der Nutzer nichts davon. Abonniere ein Disconnection-Event und benachrichtige den Account-Inhaber noch am selben Tag. PlugKit sendet account.disconnected, wenn ein Account getrennt wird oder sein Token nicht mehr funktioniert.

AB

Antoine BlancoGründer von PlugKit. Betreibt seine eigenen Instagram-, YouTube- und X-Accounts über die hier beschriebene API und den MCP-Server.