So funktioniert das Threads-API-Limit von 250 Posts pro Tag

Was ist das Threads-API-Limit von 250 Posts pro Tag?

Meta wendet das Threads-API-Limit von 250 Posts pro Tag auf den Publish-Schritt an, also kann ein Threads-Profil in jedem rollierenden Zeitraum von 24 Stunden 250 Medien-Container in Live-Beiträge verwandeln. Der Satz steht im Abschnitt Rate Limiting von Metas Threads-Überblick und lautet: „Threads profiles are limited to 250 API-published posts within a 24-hour moving period. Carousels count as a single post. This limit is enforced on the POST /{threads-user-id}/threads_publish endpoint when attempting to publish a media container.“

Drei Details in dieser Passage entscheiden, wie sich eine Warteschlange verhält. „API-published“ begrenzt die Zählung auf Beiträge, die über die Threads API laufen, statt auf solche, die in der Threads-App getippt wurden. „Moving“ schließt einen Reset um Mitternacht aus. Und threads_publish als Durchsetzungspunkt zu nennen heißt, dass das Anlegen von Containern nichts kostet, weil sich der Zähler erst bewegt, wenn ein Container zum Beitrag wird.

Meta fügt einen vierten Satz an, der direkt auf alle zielt, die einen Scheduler bauen: „We recommend 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.“

Wie funktioniert das 24-Stunden-Fenster?

Das Fenster gleitet, und jede Veröffentlichung fällt 24 Stunden nach ihrem Zeitpunkt aus der Zählung statt zu einer festen Stunde. Ein Profil, das alle 250 Slots am Montag zwischen 08:00 und 09:00 verbrennt, bekommt diese Kapazität am Dienstag zwischen 08:00 und 09:00 zurück, eine Veröffentlichung nach der anderen, nicht in einem Block um Mitternacht.

Der Quota-Endpunkt beziffert das Fenster. Sein config-Objekt trägt quota_duration: 86400, also 24 Stunden in Sekunden, neben quota_total: 250. Nichts in der Threads-Dokumentation legt die Zeitstempel einzelner Veröffentlichungen offen, also führt der einzige Weg, den aktuellen Spielraum zu kennen, über eine Abfrage der laufenden Nutzung bei Meta.

Welcher Endpunkt meldet das verbleibende Kontingent?

GET /{threads-user-id}/threads_publishing_limit gibt den Zählerstand des Profils zurück, und Meta beschreibt ihn als den Weg „To validate that a user has not exhausted their API quota limits for publishing, reply publishing, deleting, and location search.“ Zwei Felder decken das Veröffentlichen ab: quota_usage, das Meta als „Threads publishing count over the last 24 hours“ definiert, und config, das quota_total und quota_duration hält.

curl -s -X GET \
"https://graph.threads.net/v1.0/<THREADS_USER_ID>/threads_publishing_limit?fields=quota_usage,config&access_token=<ACCESS_TOKEN>"

{
  "data": [
    {
      "quota_usage": 4,
      "config": {
        "quota_total": 250,
        "quota_duration": 86400
      }
    }
  ]
}

Der Aufruf braucht die Berechtigungen threads_basic und threads_content_publish. quota_total zu lesen statt 250 fest zu verdrahten ist der Unterschied zwischen einer Integration, die eine Quota-Änderung übersteht, und einer, die sich nach einer Anhebung durch Meta noch ein Jahr lang still selbst drosselt.

Welche weiteren Kontingente hat die Threads API?

Derselbe Endpunkt meldet vier getrennte Budgets, jedes mit eigenem Feldpaar und eigener Obergrenze. Jedes davon nutzt eine quota_duration von 86400 Sekunden.

Antworten bekommen ihr eigenes Budget von 1.000, das Meta so formuliert: „Threads profiles are limited to 1,000 replies within a 24-hour moving period.“ Ein Bot, der Kommentare beantwortet, hat damit den vierfachen Spielraum eines Bots, der veröffentlicht, und verbrauchtes Antwort-Kontingent rührt die 250 nie an. Keines dieser Budgets hat mit der Grenze von 500 Zeichen im Beitragstext zu tun, die beim Anlegen des Containers statt beim Veröffentlichen greift und in dem Threads Zeichenlimit behandelt wird.

Zählt ein Karussell als ein Beitrag oder als zwanzig?

Ein Karussell zählt als eine Veröffentlichung, egal was darin steckt. Meta schreibt es zweimal: „Carousels count as a single post“ auf der Überblicksseite und „Publishing a carousel counts as a single post“ in der Karussell-Anleitung. Da ein Threads-Karussell bis zu 20 Children fasst, bewegt ein Profil, das nichts als volle Karussells veröffentlicht, 5.000 einzelne Bilder und Videos durch 250 Veröffentlichungen.

Dieses Verhältnis ist der einzige echte Hebel, den jemand auf dieses Limit hat. Zehn separate Bilder kosten zehn der 250 Slots. Dieselben zehn als ein Karussell kosten einen. Wer nahe an der Obergrenze ist, sollte Medien bündeln, bevor er mehr Spielraum verlangt, und das ist dieselbe Rechnung wie hinter dem Instagram-API-Limit von 100 Posts pro 24 Stunden.

Warum formulieren Metas zwei Seiten dasselbe Limit unterschiedlich?

Die Zahl stimmt seitenübergreifend überein, der Wortlaut nicht. Die Überblicksseite sagt „250 API-published posts within a 24-hour moving period“. Die Karussell-Anleitung sagt in einer Notiz über Schritt 3: „Profiles are limited to 250 published posts within a 24-hour period.“

Die zweite Fassung lässt „API-“ und „moving“ weg. Wörtlich gelesen würde sie Beiträge abdecken, die von Hand in der App entstehen, und zu einer festen Uhrzeit zurückgesetzt. Meta bringt die beiden nie zusammen, und nur die Überblicksseite trägt das Durchsetzungsdetail mit threads_publish, also ist der Überblick die vollständigere Fassung derselben Regel. Behandle den kürzeren Satz als Abkürzung, nicht als zweite Richtlinie.

Welchen Fehler gibt Threads zurück, wenn das Kontingent aufgebraucht ist?

Meta dokumentiert keinen Fehlercode für ein überschrittenes Veröffentlichungskontingent. Der Index der Threads API Reference listet neun Endpunktseiten und überhaupt keine Seite mit Fehlercodes, und die Troubleshooting-Seite behandelt nur Container-Ergebnisse: die status-Werte EXPIRED, ERROR, FINISHED, IN_PROGRESS und PUBLISHED sowie Video-error_message-Werte wie FAILED_DOWNLOADING_VIDEO und INVALID_ASPEC_RATIO.

Der eine Fehlerstring beim Veröffentlichen, den Meta dokumentiert, hat mit Volumen nichts zu tun. Ab dem 22. Dezember 2025 scheitert ein Beitrag mit mehr als fünf Links im Container-Schritt mit THREADS_API__LINK_LIMIT_EXCEEDED. Für die 250 gibt es keine entsprechende Konstante.

Genau diese Lücke ist der Grund, warum Meta Apps auffordert, das Limit selbst durchzusetzen. Code gegen eine undokumentierte Fehlerantwort ist geraten; Code, der vor dem Veröffentlichen quota_usage liest, prüft denselben Zähler wie Meta.

Wie unterscheidet sich das Rate-Limit pro App von den 250?

Die 250 sind ein Veröffentlichungsbudget auf Profilebene. Davon getrennt zählt jeder Aufruf der Threads API gegen die aufrufende App, und dafür gibt Meta eine Formel statt einer Konstante an: Calls within 24 hours = 4800 * Number of Impressions, wobei Impressions „the number of times any content from the app user's Threads account has entered a person's screen within the last 24 hours“ sind. Der Mindestwert für Impressions ist 10, also liegt die Untergrenze bei 48.000 Aufrufen pro Paar aus App und Nutzer.

Zwei CPU-Budgets laufen mit, 720000 * number_of_impressions für die gesamte CPU-Zeit und 2880000 * Number of Impressions für die Gesamtzeit. Dieselbe auf Impressions gebaute Form regiert das Instagram-API-Rate-Limit von 4800 Impressionen, was wenig überrascht, da beide auf Metas Infrastruktur laufen.

Ein Profil kann also 250 Veröffentlichungen erreichen und dabei weit von seinem App-Aufrufbudget entfernt sein, denn Container-Status abfragen, Insights lesen und Antworten holen verbrauchen alle Aufrufe, ohne Veröffentlichungen zu verbrauchen.

Was bedeutet das Limit für eine Planungswarteschlange?

Die 250 gehören Threads, und jedes Tool, das über die offizielle API veröffentlicht, arbeitet darin. Kein Scheduler hebt ein Plattform-Kontingent an, die Arbeit steckt also in der Form der Warteschlange: Medien zu Karussells bündeln, einen Launch über Tage strecken und quota_usage lesen, bevor ein Batch losläuft, statt nachdem eine Veröffentlichung scheitert.

Metas eigener Rat zeigt in dieselbe Richtung, denn er bittet Apps, die Planung erlauben, das Veröffentlichungslimit lokal durchzusetzen. Wie ein Threads-Beitrag überhaupt in die Warteschlange kommt, behandelt wie man Threads-Beiträge plant. Eine ganze Woche auf einen Blick zu sehen verhindert, dass ein Schwall überhaupt geplant wird, und das ist die Aufgabe eines Content-Kalenders; wer einen Monat in einer Sitzung lädt, entscheidet die Verteilung beim Bulk-Scheduling. AdaptlyPost veröffentlicht über die offizielle API auf Threads, also gilt dasselbe 250-Beiträge-Fenster; die Seite zum Threads-Planungstool erklärt, wie diese Verbindung funktioniert.

Häufig gestellte Fragen

Zählen Beiträge aus der Threads-App gegen die 250?

Metas Satz im Überblick begrenzt Profile auf 250 „API-published posts“, was Beiträge meint, die über die Threads API entstehen. Die Karussell-Seite lässt das Präfix „API-“ weg und sagt „250 published posts“, und Meta sagt nie, welche Lesart gilt. Frage GET /{threads-user-id}/threads_publishing_limit ab, wenn das manuelle Posting-Volumen hoch genug ist, um ins Gewicht zu fallen, denn dieser Endpunkt meldet, was Meta tatsächlich zählt.

Zählen Antworten gegen das Kontingent von 250 Beiträgen?

Nein. Antworten haben ein separates Budget von 1.000 innerhalb eines beweglichen 24-Stunden-Zeitraums, gemeldet über die Felder reply_quota_usage und reply_config am selben Endpunkt. Eine Antwort zu veröffentlichen senkt nie die 250, die für Beiträge zur Verfügung stehen.

Wann wird das 24-Stunden-Fenster zurückgesetzt?

Nie, denn Meta nennt es einen „24-hour moving period“. Einzelne Veröffentlichungen fallen nacheinander heraus, jeweils 24 Stunden nach ihrem Zeitpunkt. Das Feld quota_duration sagt dasselbe in Zahlen, nämlich 86400 Sekunden.

Wie viele Bilder kann ein Profil pro Tag über die Threads API veröffentlichen?

Bis zu 5.000, wenn jede Veröffentlichung ein volles Karussell ist. Meta begrenzt ein Karussell auf 20 Children und zählt es als einen Beitrag, also tragen 250 Veröffentlichungen 250 mal 20 Medien. Einzelbilder statt Karussells begrenzen dasselbe Profil auf 250 Bilder.

Verbraucht das Anlegen eines Medien-Containers Kontingent?

Meta hält fest, dass das Limit „is enforced on the POST /{threads-user-id}/threads_publish endpoint when attempting to publish a media container“, was die Zählung auf den Publish-Aufruf legt. Container haben allerdings ihre eigene Uhr: ein unveröffentlichter Container gibt EXPIRED zurück, beschrieben als „The container was not published within 24 hours and has expired.“

Wo ist das Limit von 250 Beiträgen dokumentiert?

Auf Metas Threads-Überblicksseite unter developers.facebook.com/documentation/threads/overview, im Abschnitt Rate Limiting, im Unterabschnitt Posts. Die Karussell-Anleitung unter developers.facebook.com/documentation/threads/posts wiederholt die Zahl in einer Notiz über Schritt 3, und der Endpunkt, der sie meldet, ist sowohl auf der Troubleshooting-Seite als auch in der User-Referenz dokumentiert.

Gilt das 250er-Limit für das Threads-Profil oder für die App?

Die 250 sind ein Kontingent auf Profilebene, das zum Threads-Konto selbst gehört. Parallel dazu gilt ein eigenes Rate-Limit pro App, das aus Impressions berechnet wird statt aus einer festen Zahl. Ein Profil kann seine 250 Veröffentlichungen erreichen, während die verbundene App noch reichlich Aufrufbudget übrig hat.

Kann ein Entwickler Meta bitten, das 250er-Limit anzuheben?

Metas Dokumentation nennt die Zahl 250 auf der Übersichtsseite und im Karussell-Leitfaden, ohne einen Weg zu beschreiben, ein höheres Limit zu beantragen. Der einzige dokumentierte Hebel ist das Gruppieren von Medien in Karussells, da ein Karussell unabhängig von der Zahl seiner bis zu 20 möglichen Kinder als ein Post zählt. quota_total auszulesen statt die feste Zahl 250 fest zu programmieren ist die einzige Vorbereitung, die Meta für den Tag empfiehlt, an dem sich die Zahl ändert.

Was sollte eine Planungssoftware tun, wenn ein Batch die 250er-Grenze überschreiten würde?

Meta dokumentiert keinen Fehlercode für das Überschreiten des Veröffentlichungskontingents, sodass eine Software, die auf einen Fehler wartet, nichts Verlässliches abfangen kann. Metas eigene Empfehlung lautet, quota_usage vor dem Absenden eines Batches zu prüfen und Posts lokal zurückzuhalten. Genau das verlangt Meta von jeder App, die geplante Veröffentlichungen erlaubt.

Ist das 250er-Limit von Threads dasselbe wie das Veröffentlichungslimit von Instagram?

Die Zahlen unterscheiden sich. Threads-Profile haben 250 API-veröffentlichte Posts innerhalb eines gleitenden 24-Stunden-Fensters, die vergleichbare Instagram-API-Grenze liegt bei 100 Posts pro 24 Stunden. Beide Limits laufen auf derselben Meta-Infrastruktur und beide begleiten ein App-Limit, das auf derselben Impressions-basierten Formel beruht.