Vorlaufzeiten pro Plattform-API: Wie weit im Voraus kann man einen Beitrag planen?

Wie weit im Voraus kann man einen Beitrag über die API jeder Plattform planen?

Über die offiziellen APIs hängt es vom Netzwerk ab, wie weit im Voraus man einen Beitrag planen kann: Facebook-Seitenbeiträge nehmen 10 Minuten bis 30 Tage an, Mastodon will mindestens 5 Minuten ohne dokumentierte Obergrenze, und Instagram, LinkedIn, TikTok, Threads und Pinterest akzeptieren überhaupt keinen zukünftigen Zeitpunkt. Jede Zelle unten ist aus der eigenen Dokumentation der Plattform zitiert. Wo in einer Zelle „Nicht dokumentiert“ steht, nennt die Seite der Plattform zu diesem Feld kein Limit.

Plattform, Endpunkt und Feld	Minimale Vorlaufzeit	Maximale Vorlaufzeit	Quellseite
Facebook-Seitenbeitrag, /{page-id}/feed, scheduled_publish_time	„between 10 minutes and 30 days“	30 Tage	Pages API, Posts-Leitfaden
Facebook-Seitenbeitrag, /{page-id}/feed, scheduled_publish_time	„between 10 minutes and 75 days“	75 Tage	Graph API, Page-Feed-Referenz
Facebook-Seitenvideo, /{page-id}/videos, scheduled_publish_time	„between 10 mins and 6 months“	6 Monate	Graph API, Page-Videos-Referenz
Facebook Reel, /{page-id}/video_reels, scheduled_publish_time	„greater than 10 minutes from the current time“	„within 29 days of the current date“	Video API, Reels-Publishing-Leitfaden
YouTube, videos.insert oder videos.update, status.publishAt	Nicht dokumentiert	Nicht dokumentiert	YouTube Data API, Ressource videos
Mastodon, POST /api/v1/statuses, scheduled_at	„at least 5 minutes in the future“	Nicht dokumentiert	Mastodon API, Methoden zu statuses
X Ads API, POST accounts/:account_id/scheduled_tweets, scheduled_at	Nicht dokumentiert	„up to one year in the future“	X Ads API, Creatives-Referenz
X API v2, POST /2/tweets	Kein Planungsfeld	Kein Planungsfeld	X API, Create Posts
Instagram, /<IG_ID>/media und /<IG_ID>/media_publish	Kein Planungsfeld	Kein Planungsfeld	Instagram Platform, Content Publishing
Threads, /{threads-user-id}/threads und /threads_publish	Kein Planungsfeld	Kein Planungsfeld	Threads API, Publishing-Referenz
LinkedIn, POST /rest/posts	Kein Planungsfeld	Kein Planungsfeld	LinkedIn Marketing, Posts API
TikTok, /v2/post/publish/video/init/	Kein Planungsfeld	Kein Planungsfeld	TikTok Content Posting API, Direct Post
Pinterest, POST /v5/pins	Kein Planungsfeld	Kein Planungsfeld	OpenAPI-Spezifikation der Pinterest API v5, PinCreate
Bluesky, Record app.bsky.feed.post	Kein Planungsfeld	Kein Planungsfeld	Lexicon app.bsky.feed.post

Aus der Tabelle ergeben sich zwei Regeln. Das Minimum ist immer eine serverseitige Prüfung gegen die Uhr der Plattform, nie gegen Ihre. Das Maximum, wo es eines gibt, gilt für den Moment der API-Anfrage, nicht für den Moment, in dem Sie den Beitrag entworfen haben.

Warum veröffentlicht Meta vier verschiedene Maxima für Facebook?

Weil vier Meta-Seiten einen Bereich für scheduled_publish_time nennen und keine zwei davon bei der Obergrenze übereinstimmen. Das Minimum ist durchgehend 10 Minuten. Das Maximum nicht.

Der Pages-API-Leitfaden sagt: „The publish date must be between 10 minutes and 30 days from the time of the API request.“ Die Page-Feed-Referenz sagt für denselben Parameter am selben Endpunkt /feed: „UNIX timestamp indicating when post should go live. Must be date between 10 minutes and 75 days from the time of the API request.“ Die Page-Videos-Referenz sagt, die Veröffentlichungszeit eines Videos „should be between 10 mins and 6 months from the time of publishing the video.“ Der Reels-Publishing-Leitfaden sagt „the publish time must be greater than 10 minutes from the current time and within 29 days of the current date, and video_state must be set to 'SCHEDULED'.“

Keine dieser Seiten sagt, welche Zahl gilt, und keine erwähnt die anderen. Die Angaben von 30 und 75 Tagen widersprechen sich an einem einzigen Endpunkt, also funktioniert ein Tool, das 75 Tage erlaubt, nur, wenn die Referenz stimmt. Stimmt der Leitfaden, scheitert jede Anfrage nach Tag 30. Feed-Beiträge auf 30 Tage zu begrenzen funktioniert, egal welche Seite recht hat, und Reels auf 29 Tage zu begrenzen bleibt innerhalb der einzigen Zahl, die Meta für sie nennt. Das vollständige Feld, seine Formate und seine Fehler behandelt das Zeitfenster von Facebook scheduled_publish_time.

Der Reels-Leitfaden fügt ein zweites Limit hinzu, das für Warteschlangen zählt. Er sagt, die Reels API „is limited to 30 API-published posts within a 24-hour moving period“, und dass „Meta recommends that your app also enforces the publishing rate limit, especially if your app allows app users to schedule posts to be published in the future.“

Welche Plattformen dokumentieren keine maximale Vorlaufzeit?

YouTube und Mastodon. Keine der beiden Seiten nennt eine Obergrenze, also lautet die ehrliche Antwort für beide, dass die Plattform keine veröffentlicht.

YouTubes Ressource videos beschreibt status.publishAt als „The date and time when the video is scheduled to publish“, ergänzt, dass „It can be set only if the privacy status of the video is private“, und nennt weder Minimum noch Maximum. Sie beschreibt allerdings, was am nahen Ende passiert: „If your request schedules a video to be published at some time in the past, the video will be published right away.“ YouTube hat also keine minimale Vorlaufzeit im Sinne einer Ablehnung. Ein Zeitpunkt in der Vergangenheit bedeutet: jetzt veröffentlichen. Jedes publishAt-Feld von YouTube und wie jedes scheitert behandelt die Regeln zu Privatsphäre und Aktualisierung drumherum.

Mastodon dokumentiert die Untergrenze und belässt es dabei. Der Parameter scheduled_at auf POST /api/v1/statuses ist eine „Datetime at which to schedule a status“, die „Must be at least 5 minutes in the future.“ Die Seite nennt kein Maximum. Der Server-Quellcode setzt diese Untergrenze streng durch und fügt Obergrenzen pro Konto hinzu, die die Doku weglässt, alles dargelegt in warum scheduled_at in der Mastodon API 5 Minuten Vorlauf braucht.

Welche Plattformen haben überhaupt kein Planungsfeld?

Instagram, Threads, LinkedIn, TikTok, Pinterest, Bluesky und die X API v2. Bei allen sieben ist ein geplanter Beitrag einer, den ein Planungstool auf seinen eigenen Servern hält und zum gegebenen Zeitpunkt über den normalen Create-Aufruf veröffentlicht. Die Plattform sieht immer nur eine sofortige Veröffentlichung.

Die Dokumentationen machen das auf unterschiedliche Weise deutlich. LinkedIns Posts API sagt über lifecycleState: „PUBLISHED is the only accepted field during creation.“ Instagrams Content-Publishing-Leitfaden geht davon aus, dass die App das Warten übernimmt. Er bittet Apps, das Veröffentlichungslimit selbst durchzusetzen, „especially if your app allows app users to schedule posts to be published in the future.“ Das Schema PinCreate von Pinterest in der OpenAPI-Spezifikation v5 listet ai_disclosures, alt_text, board_id, board_section_id, description, dominant_color, link, media_source, parent_pin_id, sponsor_id und title auf, ohne Zeitfeld. Auch der Body von POST /2/tweets in der X API v2 hat kein Zeitfeld. Bluesky-Post-Records haben ein createdAt, aber das Lexicon nennt es einen „Client-declared timestamp when this post was originally created“, keinen Veröffentlichungszeitpunkt.

Ohne Warteschlange auf Plattformseite zählen die Lebensdauern der Zwischenobjekte. Sie können sie nicht Tage im Voraus vorbereiten:

Plattform	Objekt	Dokumentierte Zeitregel
Instagram	Media-Container	EXPIRED: „The container was not published within 24 hours and has expired.“
TikTok	upload_url von /v2/post/publish/video/init/	„valid for one hour after issuance“
Threads	Media-Container	Meta empfiehlt, „on average 30 seconds before publishing“ zu warten

Ein Tool, das einen Instagram-Beitrag für nächsten Monat plant, behält Medien und Bildunterschrift also selbst. Es erstellt den Container kurz vor dem Veröffentlichungszeitpunkt und veröffentlicht innerhalb von 24 Stunden nach der Erstellung. Bei diesen sieben Netzwerken hängt es vom Tool ab, nicht von der API, wie weit Sie vorausplanen können.

Einen Instagram-Beitrag für nächsten Monat planen

1

Speichern. Das Tool hält Medien und Text auf den eigenen Servern.

2

Warten. Instagram sieht nichts, weil die Endpunkte keine Veröffentlichungszeit annehmen.

3

Container anlegen. Kurz vor dem Veröffentlichungszeitpunkt, denn ein nicht veröffentlichter Container läuft nach 24 Stunden ab.

4

Veröffentlichen. Über den normalen Erstellungsaufruf, innerhalb von 24 Stunden nach dem Anlegen des Containers.

Was erlaubt die X Ads API für geplante Tweets?

Bis zu einem Jahr im Voraus, minutengenau und nur für Werbetreibende. Der Parameter scheduled_at auf POST accounts/:account_id/scheduled_tweets ist „The time, expressed in ISO 8601, that the Tweet should be published (or go live)“, mit zwei Hinweisen: „Tweets can only be scheduled up to one year in the future“ und „Tweets should only be scheduled at minute-granularity; seconds will be ignored.“

In den Standardwerten steckt ein Haken. Der Parameter nullcast desselben Endpunkts steht standardmäßig auf true, was die Doku als Erstellen „a nullcasted (or 'Promoted-only') Tweet.“ definiert. Ein mit Standardwerten erstellter geplanter Tweet erscheint nicht als organischer Beitrag in der Profil-Timeline. Der Endpunkt verlangt außerdem as_user_id, und der Werbetreibende „must grant your handle (or handles) access to their ads account via ads.x.com.“ Das ist ein anderes Setup als organisches Posten, das über POST /2/tweets läuft und kein Planungsfeld hat.

Welches Vorlauffenster sollte ein Planungstool durchsetzen?

Setzen Sie pro Plattform die strengste dokumentierte Grenze durch, gemessen an einer synchronisierten Serveruhr, und lehnen Sie alles außerhalb davon vor dem API-Aufruf ab. Frühes Ablehnen gibt der Person eine verständliche Fehlermeldung statt eines generischen 100 oder 422.

Plattform	Mindestens durchsetzen	Höchstens durchsetzen
Facebook-Feed-Beiträge	10 Minuten plus Uhrenpuffer	30 Tage
Facebook Reels	10 Minuten plus Uhrenpuffer	29 Tage
Facebook-Videos	10 Minuten plus Uhrenpuffer	6 Monate
Mastodon	5 Minuten plus Uhrenpuffer	Kein Plattformlimit
YouTube	Jeder zukünftige Zeitpunkt; vergangene Zeitpunkte blockieren	Kein Plattformlimit
Geplante Tweets in X Ads	Keine Untergrenze der Plattform	Ein Jahr

Der Puffer zählt, weil jedes dieser Minima auf der Uhr der Plattform geprüft wird, im Moment, in dem die Anfrage ankommt. Ein Beitrag, der 10 Minuten und 5 Sekunden in der Zukunft eingeplant ist, kann scheitern, wenn die Anfrage langsam ist oder die lokale Uhr nachgeht. Bei Netzwerken ohne Planungsfeld ist die Vorlaufzeit das, was das Tool unterstützt, und die einzige Frist der Plattform ist die Lebensdauer der Objekte aus der vorherigen Tabelle.

Häufig gestellte Fragen

Wie weit im Voraus kann man einen Facebook-Beitrag über die API planen?

Metas Pages-API-Leitfaden sagt zwischen 10 Minuten und 30 Tagen, während die Page-Feed-Referenz für dasselbe Feld auf /feed zwischen 10 Minuten und 75 Tagen sagt. Seitenvideos erlauben bis zu 6 Monate und Reels bis zu 29 Tage. Feed-Beiträge auf 30 Tage zu begrenzen bleibt innerhalb beider Feed-Angaben.

Kann man Instagram-Beiträge über die Instagram API planen?

Nicht mit einem Zeitplan auf Plattformseite. Die Content-Publishing-Endpunkte /<IG_ID>/media und /<IG_ID>/media_publish nehmen keinen Veröffentlichungszeitpunkt an, also hält ein Planungstool den Beitrag zurück und veröffentlicht ihn zum gewählten Moment. Container verfallen, wenn sie „not published within 24 hours“ sind.

Gibt es bei YouTube eine maximale Planungszeit?

Googles Ressource videos dokumentiert für status.publishAt keine. Sie sagt nur, dass das Feld „can be set only if the privacy status of the video is private“, und dass ein Zeitpunkt in der Vergangenheit das Video „right away“ veröffentlicht.

Was ist die kürzeste Vorlaufzeit, die eine Plattform-API akzeptiert?

Mastodons dokumentierte Untergrenze ist „at least 5 minutes in the future“. Bei Facebook sind es 10 Minuten auf jeder Meta-Seite, die einen Bereich für scheduled_publish_time nennt. Die Page-Photos-Referenz nennt überhaupt keinen Bereich. YouTube dokumentiert keine Untergrenze und veröffentlicht vergangene Zeitpunkte sofort.

Unterstützt die API von LinkedIn geplante Beiträge?

Nein. Die Posts API sagt über lifecycleState, dass „PUBLISHED is the only accepted field during creation“, und die Create-Anfrage hat kein Zeitfeld. Tools, die LinkedIn-Beiträge planen, speichern sie und rufen POST /rest/posts zum gewählten Zeitpunkt auf.

Wie weit im Voraus kann man einen Tweet über die API planen?

Nur die X Ads API hat ein Planungsfeld. Ihr Endpunkt scheduled_tweets erlaubt Zeitpunkte „up to one year in the future“, ignoriert Sekunden und setzt nullcast standardmäßig auf true, wodurch der Tweet nur beworben erscheint. Der Endpunkt POST /2/tweets der X API v2 hat kein Planungsfeld.

Wie weit im Voraus kann man ein Facebook-Reel über die API planen?

Laut Reels-Publishing-Leitfaden muss die Veröffentlichungszeit mehr als 10 Minuten nach der aktuellen Zeit und innerhalb von 29 Tagen ab dem aktuellen Datum liegen, und video_state muss auf "SCHEDULED" stehen. Für Reels gilt außerdem ein Limit von 30 per API veröffentlichten Beiträgen in einem gleitenden 24-Stunden-Zeitraum. Meta empfiehlt, dieses Limit auch in der eigenen App durchzusetzen, wenn sie das Planen erlaubt.

Hat die Mastodon API eine maximale Planungszeit?

Die Dokumentation nennt keine. Sie verlangt nur, dass scheduled_at mindestens 5 Minuten in der Zukunft liegt. Der Server-Quellcode setzt zusätzlich Limits pro Konto, die in der Doku fehlen, deshalb sollte ein Planungstool nicht von einer unbegrenzten Warteschlange ausgehen.

Kann man Threads- oder TikTok-Beiträge über deren APIs planen?

Keine der beiden hat ein Planungsfeld, deshalb hält ein Planungstool den Beitrag selbst und veröffentlicht ihn zum gewählten Zeitpunkt. Zeitregeln gibt es nur für Zwischenobjekte. Die upload_url von TikTok aus /v2/post/publish/video/init/ ist eine Stunde nach der Ausgabe gültig, und Meta empfiehlt, vor dem Veröffentlichen eines Threads-Containers im Schnitt 30 Sekunden zu warten.

Warum kann ein Facebook-Beitrag scheitern, der genau 10 Minuten im Voraus geplant ist?

Jedes Minimum wird beim Eingang der Anfrage gegen die Uhr der Plattform geprüft. Ein Beitrag mit 10 Minuten und 5 Sekunden Vorlauf kann scheitern, wenn die Anfrage langsam ist oder die lokale Uhr nachgeht. Planen Sie deshalb einen Uhrenpuffer zur 10-Minuten-Untergrenze ein und lehnen Sie alles außerhalb des Fensters ab, bevor Sie die API aufrufen.