Das Instagram-API-Rate-Limit beträgt das 4800-Fache Ihrer Impressionen

Was ist das Instagram-API-Rate-Limit?

Eine einzige Formel definiert das Instagram-API-Rate-Limit, und Meta druckt sie sowohl in der Graph-API-Referenz zum Rate-Limiting als auch in der Übersicht zur Instagram Platform als eine Zeile: Calls within 24 hours = 4800 * Number of Impressions.

Der Satz darum herum zählt genauso viel wie die Formel. Meta schreibt: „Calls to the Instagram Platform endpoints, excluding messaging, are counted against the calling app's call count. An app's call count is unique for each app and app user pair, and is the number of calls the app has made in a rolling 24 hour window.“

In diesem Satz stecken drei Einschränkungen. Die Zählung gehört der App, nicht dem Konto. Sie ist auf ein Paar aus einer App und einem App-Nutzer bezogen, sodass ein vielbeschäftigter Kunde einen ruhigen nicht aushungern kann. Und das Fenster rolliert, also wird um Mitternacht nichts zurückgesetzt. Aufrufe fallen einzeln heraus, jeweils 24 Stunden nachdem sie gemacht wurden.

Die Instagram Platform sitzt in Metas Kategorie Business Use Case und nicht in der älteren Kategorie Platform Rate Limits. Anfragen der Marketing API und von Instagram unterliegen den Business-Use-Case-Limits, einfache Graph-API-Anfragen den Platform-Limits. Wo beides greifen könnte, löst Meta es in einer Zeile auf: „If both Platform and Business Use Case rate limits can be applied to a request, BUC rate limits will be applied.“

Worauf bezieht sich der Multiplikator 4800?

Auf Impressionen, und Meta definiert das Wort eng: „The Number of Impressions is the number of times any content from the app user's Instagram professional account has entered a person's screen within the last 24 hours.“

Lesen Sie das als Bildschirmzählung, nicht als Followerzahl, nicht als Beitragszahl und nicht als Reichweite. Gezählt werden Erscheinungen, also steuert eine Person, die an vier Ihrer Beiträge vorbeiscrollt, vier bei. Es umfasst „any content“ des Kontos, also zählen alte Beiträge, die Traffic ziehen, genauso viel wie der von heute Morgen. Und gemessen wird über dieselben rollierenden 24 Stunden wie die Aufrufe, die daraus finanziert werden, was das Kontingent kontinuierlich statt in Stufen bewegt.

Das ergibt ein Budget, das mit Aufmerksamkeit wächst. Ein Konto, dessen Beiträge am Vortag 50.000 Mal auf Bildschirme gelangt sind, finanziert 240.000.000 Aufrufe, eine Zahl, der kein Veröffentlichungs-Workflow nahekommt. Die Formel beißt nur am unteren Ende, denn Meta veröffentlicht keinen Mindestwert: 4800 mal null Impressionen sind null Aufrufe, und nirgends in der Referenz zum Rate-Limiting nennt Meta ein Mindestkontingent für ein Konto, das niemand gesehen hat.

Dieselbe Struktur taucht anderswo in Metas Tabelle auf. Aufrufe der Pages API mit einem Page- oder System-User-Token nutzen Calls within 24 hours = 4800 * Number of Engaged Users, und LeadGen nutzt Calls within 24 hours = 4800 * Leads Generated. Der Multiplikator 4800 ist Metas Hausnummer für einen Business Use Case über 24 Stunden; nur der multiplizierte Wert ändert sich.

Wie liest man den Header X-Business-Use-Case-Usage?

Meta gibt die Nutzung in einem Response-Header zurück und nicht im Body: „All API responses made by your app that are rate limited using the BUC logic include an X-Business-Use-Case-Usage HTTP header with a JSON-formatted string that describes current application rate limit usage. This header can return up to 32 objects in one call.“

Der Headerwert ist ein JSON-Objekt, das nach Business-ID geschlüsselt ist, und jeder Eintrag trägt diese Felder.

Feld	Was es laut Meta enthält
business-id	Die ID des Unternehmens, das mit dem Token verknüpft ist, über den die API-Aufrufe laufen
call_count	Eine ganze Zahl, die den Prozentsatz der erlaubten Aufrufe angibt, die Ihre App gemacht hat
total_cputime	Eine ganze Zahl, die den Prozentsatz der für die Abfrageverarbeitung zugeteilten CPU-Zeit angibt
total_time	Eine ganze Zahl, die den Prozentsatz der für die Abfrageverarbeitung zugeteilten Gesamtzeit angibt
estimated_time_to_regain_access	Zeit in Minuten, bis Aufrufe nicht mehr gedrosselt werden
type	Art des angewendeten Rate Limits, einer aus ads_insights, ads_management, custom_audience, instagram, leadgen, messenger oder pages

Für Instagram-Arbeit ist type das Feld, auf das Sie filtern, und instagram der Wert, den Sie suchen. Eine App, die auch Pages oder Ads berührt, bekommt im selben Header mehrere Objekte zurück, und wer das falsche liest, erfährt etwas über das falsche Budget.

Jede der drei Nutzungszahlen ist ein Prozentwert, keine Anzahl. call_count auf 62 bedeutet, dass 62 Prozent des Kontingents verbraucht sind, und Meta nennt Ihnen nie den Nenner, weil der Nenner jene Impressionszahl ist, die laufend neu berechnet wird. Kein Endpunkt gibt Ihre aktuelle Aufrufobergrenze als ganze Zahl zurück.

Der Header erscheint auch nicht bei jeder Antwort. Metas Formulierung lautet, dass Echtzeit-Nutzungsstatistiken „included with most API responses once enough calls have been made to an endpoint“ sind. Behandeln Sie einen fehlenden Header als fehlende Information und nicht als null Nutzung.

Warum sagt der Header eine Stunde, wenn die Formel 24 Stunden sagt?

Weil Metas zwei Seiten sich widersprechen, und der Widerspruch steht live im selben Dokument. Der Instagram-Abschnitt spricht von einem „rolling 24 hour window“. Die Header-Tabelle ein paar Bildschirme darunter definiert call_count als „A whole number expressing the percentage of allowed calls made by your app over a rolling one hour period“.

Beide Sätze beschreiben dasselbe Feld desselben Headers derselben API. Einer davon ist für Instagram falsch. Die Formulierung mit der einen Stunde passt zum Abschnitt Platform Rate Limits weiter oben auf der Seite, wo Aufrufe auf App-Ebene tatsächlich stündlich gemessen werden, was der wahrscheinlichste Ursprung der Unstimmigkeit ist.

In der Dokumentation löst das nichts auf, also planen Sie mit dem längeren Fenster. Wenn Sie annehmen, der Zähler leert sich in einer Stunde, und er leert sich tatsächlich in 24, laufen Sie mit Wiederholungen gegen eine Wand. Wenn Sie 24 annehmen und er leert sich in einer, haben Sie länger gewartet als nötig. Nur einer dieser beiden Fehler zerlegt einen Veröffentlichungsplan.

Eine zweite veröffentlichte Lücke steckt in den Fehlertabellen. Metas Liste der Business-Use-Case-Fehler nennt für den Typ Instagram den error code 80002, ohne Subcode. Die Referenz der Instagram-Platform-Fehlercodes, also die Seite, die Sie beim Debuggen einer Veröffentlichung tatsächlich aufschlagen, führt 80002 nirgends auf. Diese Zuordnung müssen Sie selbst machen.

Was passiert, wenn call_count 100 erreicht?

Anfragen scheitern mit einem eigenen Fehlercode. Meta schreibt: „When your app reaches its Business Use Case rate limit, subsequent requests made by your app will fail and the API will respond with an error code.“ Für den Typ Instagram ist dieser Code 80002.

CPU- und Laufzeit drosseln unabhängig vom Aufrufvolumen. Meta wiederholt dieselben zwei Zeilen unter jedem Business Use Case: „When total_cputime reaches 100, calls may be throttled“ und „When total_time reaches 100, calls may be throttled.“ Es reicht, wenn eines der drei die 100 erreicht. Eine kleine Zahl schwerer Abfragen kann total_cputime ausschöpfen, während call_count noch einstellig ist.

Sobald Sie gedrosselt sind, trägt estimated_time_to_regain_access die Wartezeit in Minuten, und die Anweisung, die darauf folgt, ist die wichtige: „When the limit has been reached, stop making API calls. Continuing to make calls will continue to increase your call count, which will increase the time before calls will be successful again.“

Erneute Versuche verlängern die Sperre. Das ist ungewöhnlich genug, um darum herum zu bauen, denn ein voreingestelltes exponentielles Backoff sendet trotzdem Anfragen, und jede einzelne verlängert die Strafe. Das richtige Verhalten bei 80002 ist, die Warteschlange anzuhalten, bis der Header etwas anderes sagt. Dieselbe Disziplin zahlt sich bei der täglichen Veröffentlichungsquote aus, die eine eigene Obergrenze mit eigenem Fehler ist.

Metas übriger Rat betrifft die Verteilung statt des Volumens: „Spread out queries evenly to avoid traffic spikes“ und „Use filters to limit the data response size and avoid calls that request overlapping data.“ Dazu gibt es eine Zählregel, die alle erwischt, die IDs bündeln. Meta hält fest, dass „each ID counts as one API call“, und führt es vor: Drei getrennte Anfragen mit je einer ID zählen als drei Aufrufe, und eine Anfrage mit ids=4,5,6 zählt ebenfalls als drei.

Zwei Reaktionen auf Fehler 80002

Warteschlange stoppen

• call_count steigt nicht weiter
• estimated_time_to_regain_access zählt herunter
• Aufrufe funktionieren wieder, sobald die Wartezeit endet

Weiter versuchen

• jeder erneute Versuch erhöht call_count weiter
• estimated_time_to_regain_access wächst
• die Wartezeit bis Aufrufe wieder funktionieren wird länger

Welche Instagram-Endpunkte liegen außerhalb dieses Limits?

Zwei Familien, und Meta benennt sie ausdrücklich.

Oberfläche	Geltendes Limit
Veröffentlichen, Medien, Insights, Kommentare	4800 * Number of Impressions pro 24 Stunden
Business Discovery, Hashtag Search	Platform Rate Limits, nicht Business Use Case
Conversations API	2 Aufrufe pro Sekunde pro professionellem Konto
Send API, Text und Links	100 Aufrufe pro Sekunde pro professionellem Konto
Send API, Audio oder Video	10 Aufrufe pro Sekunde pro professionellem Konto
Private Replies, Live-Kommentare	100 Aufrufe pro Sekunde pro professionellem Konto
Private Replies, Beiträge und Reels	750 Aufrufe pro Stunde pro professionellem Konto

Messaging ist vollständig aus der Impressionsformel herausgenommen und läuft stattdessen über Obergrenzen pro Sekunde und pro Stunde. Business Discovery und Hashtag Search fallen auf die Platform Rate Limits zurück, wo die Formel auf App-Ebene Calls within one hour = 200 * Number of Users lautet.

Das Rate-Limit ist außerdem nicht die Veröffentlichungsquote. Es sind getrennte Systeme mit getrennten Fehlern, und sie zu verwechseln kostet Debugging-Zeit: Eine durch Volumen blockierte Veröffentlichung liefert 80002, während eine Veröffentlichung, die an der Quote für Inhaltsveröffentlichung scheitert, Code 9, Subcode 2207042 zurückgibt. Andere Netzwerke teilen das genauso auf, ob das nun die Anfrageobergrenzen sind, die Bluesky pro Endpunkt veröffentlicht oder das tägliche Einheitenbudget, das YouTube misst und auf Antrag anhebt.

Häufig gestellte Fragen

Wie lautet die Formel für das Instagram-API-Rate-Limit?

Calls within 24 hours = 4800 * Number of Impressions. Meta veröffentlicht sie in der Graph-API-Referenz zum Rate-Limiting und wiederholt sie in der Übersicht zur Instagram Platform.

Was zählt beim Instagram-Rate-Limit als Impression?

Meta definiert es als „the number of times any content from the app user's Instagram professional account has entered a person's screen within the last 24 hours“. Gezählt werden Erscheinungen beliebiger Inhalte, nicht Follower und nicht Beiträge.

Welcher Fehlercode bedeutet, dass das Instagram-API-Rate-Limit erreicht wurde?

Fehlercode 80002. Meta führt ihn beim Business-Use-Case-Typ Instagram ohne Subcode auf und wiederholt ihn nicht in der Referenz der Instagram-Platform-Fehlercodes.

Wie prüft man die aktuelle Nutzung des Instagram-API-Rate-Limits?

Lesen Sie den Response-Header X-Business-Use-Case-Usage, suchen Sie das Objekt, bei dem type gleich instagram ist, und prüfen Sie call_count, total_cputime und total_time. Alle drei sind Prozentwerte des Kontingents.

Verschlimmert ein erneuter Versuch nach einem Rate-Limit-Fehler die Lage?

Ja. Meta schreibt, dass weitere Aufrufe „will continue to increase your call count, which will increase the time before calls will be successful again“. Halten Sie die Warteschlange an und lesen Sie estimated_time_to_regain_access.

Fallen Instagrams Messaging-Endpunkte unter die 4800er-Formel?

Nein. Meta nimmt Messaging aus der Impressionsformel heraus und veröffentlicht stattdessen Obergrenzen pro Sekunde und pro Stunde für die Conversations, Send und Private Replies APIs.

Setzt sich das Instagram-API-Rate-Limit zu einer festen Uhrzeit jeden Tag zurück?

Es setzt sich nicht um Mitternacht oder zu einer anderen festen Uhrzeit zurück. Meta zählt Aufrufe in einem rollierenden 24-Stunden-Fenster, sodass jeder Aufruf genau 24 Stunden nach seiner Ausführung aus der Zählung fällt. Das Kontingent bewegt sich fortlaufend, statt nach einem Zeitplan auf null zu springen.

Wird die Instagram-API-Aufrufzahl von allen Apps geteilt, die mit meinem Konto verbunden sind?

Jede App führt ihre eigene Zählung. Meta ordnet den Aufrufzähler einem einzigen Paar aus App und App-Nutzer zu, sodass eine stark genutzte App nicht das Kontingent einer anderen App verbraucht, die auf dasselbe Konto zugreift.

Wie unterscheidet sich das Instagram-API-Rate-Limit von der täglichen Veröffentlichungsquote?

Es handelt sich um getrennte Systeme mit getrennten Fehlern. Das hier beschriebene Rate-Limit blockiert mit Fehlercode 80002, wenn call_count, total_cputime oder total_time 100 erreicht. Die tägliche Veröffentlichungsquote ist eine andere Grenze und schlägt mit Code 9, Subcode 2207042 fehl, sodass eine Blockierung der einen Art nie die andere erklärt.

Zählen Aufrufe an Business Discovery und Hashtag Search zur 4800er-Formel?

Sie fallen nicht darunter. Beide Endpunkte laufen unter Metas älterer Kategorie Platform Rate Limits statt Business Use Case, wo die geltende Formel 200 mal die Anzahl der Nutzer pro Stunde lautet statt 4800 mal Impressionen.