Wenn du programmatisch veröffentlichst, gelten zwei separate Ratenlimits, und nur eines davon hast du unter Kontrolle.
Die zwei Ebenen
Das Limit der Plattform. Jedes soziale Netzwerk begrenzt, wie viel eine Anwendung über seine API tun kann, mit eigenem Zeitfenster, eigenen Headern und eigenem Verhalten bei Überschreitung. Diese unterscheiden sich pro Plattform und ändern sich ohne viel Vorwarnung.
Das Limit deines Anbieters. Wenn du über eine einheitliche API veröffentlichst, hat auch dieser Dienst ein Limit, meist gebunden an deinen Tarif.
Das zweite ist leicht abzulesen und einzuplanen. Das erste ist das, das beißt, weil du es bei Nutzung einer einheitlichen API nie direkt siehst. Der Anbieter fängt es ab, was ein großer Teil dessen ist, wofür du bezahlst, aber es verschwindet nicht: Drosselt eine Plattform alle, bedeutet das immer noch, dass dein Beitrag sich verzögert.
Für Verzögerung gestalten, nicht nur für Fehler
Der häufigste Fehler in einer Publishing-Pipeline ist, “angenommen” mit “veröffentlicht” gleichzusetzen.
Auf mehreren Plattformen liefert das Einreichen eines Beitrags Erfolg zurück, und die eigentliche Veröffentlichung passiert danach. Der Fehlschlag kommt also später an, außerhalb des Kanals, lange nachdem deine Anfrage 200 zurückgegeben hat. Hat dein Datenmodell nur “gesendet” und “fehlgeschlagen”, gibt es keinen Platz für “wir glauben, das wird gerade veröffentlicht”.
Gestalte für drei Zustände und mach den schwebenden sichtbar.
Praktische Regeln
Exponentiell zurückhalten. Bei einem 429 warten und mit steigender Verzögerung erneut versuchen. Sofortige Wiederholungen verschlimmern die Lage und können eine Drosselung verlängern.
Wiederholungen deckeln. Eine Pipeline, die endlos wiederholt, ist der Weg, auf dem ein Kontingent in Minuten verschwindet. Aufgeben, laut protokollieren und einen Menschen schauen lassen.
Ein Create niemals blind wiederholen. Läuft eine Create-Anfrage in ein Timeout, weißt du nicht, ob sie erfolgreich war. Ein erneuter Versuch kann doppelte Beiträge erzeugen, was schlimmer ist als der ursprüngliche Fehler. Prüfe vor dem Wiederholen, oder nutz einen Ansatz, der die Wiederholung sicher macht.
Batchen, wo ein Endpunkt es unterstützt. Eine Anfrage, die viele Beiträge erstellt, kostet eine Anfrage. Dieselbe Arbeit als fünfzig einzelne Aufrufe kostet fünfzig.
BulkPublishs eigene Limits
| Free | Pro | Business | |
|---|---|---|---|
| API-Anfragen/Tag | 30 | 5.000 | 50.000 |
| API-Schlüssel | 1 | 5 | 10 |
| Beiträge | 3/Tag | 30/Tag | Unbegrenzt |
Die 30 Anfragen pro Tag im kostenlosen Tarif sind absichtlich dafür bemessen, die API zu testen und etwas Leichtes und Persönliches zu betreiben. Sie reichen nicht für eine echte Pipeline, und eine Schleife ohne Backoff erschöpft sie in Sekunden.
Beachte, dass API-Anfragen und Beiträge separate Limits sind. Kanäle auflisten, Status prüfen und Medien hochladen verbrauchen alle Anfragen, ohne einen Beitrag zu erstellen, sodass das Anfragebudget nur dann weiter reicht, als die Beitragszahl vermuten lässt, wenn du es sorgfältig nutzt.
Mehrere Schlüssel sind für Trennung, nicht für mehr Kapazität
Bezahlte Tarife enthalten mehrere API-Schlüssel, und der Grund ist nicht zusätzlicher Durchsatz. Es geht darum, dass verschiedene Dinge verschiedene Zugangsdaten halten können: deine Produktions-Pipeline, eine Staging-Umgebung, ein KI-Agent.
Der Wert zeigt sich, wenn etwas schiefgeht. Du widerrufst um 2 Uhr nachts einen Schlüssel, statt den einen Zugangsdatensatz zu rotieren, den sich alles teilt.
Eine sinnvolle Form für einen Publishing-Job
- Kanäle einmal beim Start nachschlagen, nicht pro Beitrag
- Medien hochladen, dann Beiträge erstellen, die auf die IDs verweisen
- Batch-Endpunkte nutzen, wo sie existieren
- 429 mit exponentiellem Backoff und einer Wiederholungsobergrenze behandeln
- Jeden Fehlschlag mit dem Antwortkörper protokollieren, denn niemand schaut zu
Die Kurzfassung
Zwei Limits gelten: das der Plattform, das du durch eine einheitliche API nicht sehen kannst, und das deines Anbieters, das du siehst. Exponentiell zurückhalten, Wiederholungen deckeln, ein Create nie blind wiederholen, batchen wo möglich. Und behandle “angenommen” als einen Zustand, der sich von “veröffentlicht” unterscheidet, denn auf mehreren Plattformen ist er es wirklich.