Der Planungsteil eines Social-Media-Planers ist ein Wochenendprojekt. Eine Warteschlange, ein Worker, ein Cron-Job. Das ist wirklich nicht schwer, und genau deshalb liegt die Schätzung immer daneben.
Alles Teure liegt auf der anderen Seite davon.
Der Teil, der einfach ist
Eine Tabelle mit Beiträgen mit einer geplanten Zeit, ein Worker, der aufwacht, fällige Beiträge findet und sie veröffentlicht. Füge einen Retry hinzu und du bist fertig.
Wenn du das als Lernprojekt oder für eine einzige Plattform baust, die du selbst kontrollierst, hör hier auf zu lesen. Der Rest handelt davon, was passiert, wenn echte Konten und mehrere Plattformen im Spiel sind.
Das Datenmodell, das du wirklich brauchst
Mehr Zustände, als man erwartet:
- draft, erstellt, aber nicht eingeplant
- scheduled, für einen Zeitpunkt eingeplant
- processing, an die Plattform gesendet, Ergebnis unbekannt
- published, bestätigt
- failed, mit einem Grund
- partial, bei einigen Zielen veröffentlicht, bei anderen nicht
processing existiert, weil mehrere Plattformen einen Beitrag annehmen und asynchron veröffentlichen. Ein 200er ist keine Veröffentlichung, und das Ergebnis kommt später außerhalb des Requests an. Ohne diesen Zustand behauptet deine UI einen Erfolg, der manchmal falsch ist.
partial existiert, weil ein Beitrag üblicherweise mehrere Plattformen anvisiert. Drei gelingen, eine schlägt fehl. Weder “published” noch “failed” trifft zu, und es in eines von beiden zu zwingen, erzeugt ein Produkt, das seine Nutzer belügt.
Du brauchst außerdem Zeilen pro Ziel statt eines einzigen Status pro Beitrag, weil der Fehler pro Plattform auftritt.
Zeitzonen
Speichere den Zeitpunkt und die IANA-Zeitzone, nicht einen Offset.
“Jeden Werktag um 9 Uhr Ortszeit” ist vor und nach einer Zeitumstellung ein anderer UTC-Zeitpunkt. Nur UTC zu speichern funktioniert bis März, dann verschiebt sich alles um eine Stunde, und die Fehlerberichte sind verwirrend, weil es die halbe Zeit korrekt ist.
Die Plattformarbeit
Hier bricht die Schätzung ein. Pro Plattform:
Ein eigener OAuth-Flow. Unterschiedliche Scopes, unterschiedliche Token-Laufzeiten, unterschiedliche Zustimmungsbildschirme.
Ein eigener Refresh-Job. Das ist derjenige, der wirklich wehtut. Tokens laufen ab, das Refresh schlägt still fehl, und niemand bemerkt es, bis ein geplanter Beitrag nicht rausgeht. Du brauchst geplantes Refresh, Monitoring für fehlgeschlagenes Refresh, einen Zustand für getrennte Verbindungen und einen Wiederverbindungs-Flow. Das ist mehr Aufwand als der OAuth-Flow selbst.
Eine eigene Medien-Pipeline. Eine Plattform ruft eine URL ab, eine will einen fortsetzbaren, in Chunks aufgeteilten Upload, eine will bestimmte Abmessungen oder Codecs. Du wirst hosten und möglicherweise transkodieren müssen.
Ein eigenes Rate-Limit, mit eigenem Zeitfenster und eigenem Verhalten bei Überschreitung.
App-Review. Mehrere Plattformen setzen das Veröffentlichen hinter ein Review deiner App voraus, das eine Datenschutzerklärung und manchmal ein Demo-Video umfasst. Das ist Kalenderzeit, die du nicht kontrollierst, und sie kann abgelehnt werden.
Ständiger Wandel. API-Versionen werden abgekündigt, Felder umbenannt, Berechtigungen verschärft, nach dem Zeitplan der Plattformen. Jede davon ist ungeplante Arbeit mit einer Deadline, die du nicht gesetzt hast.
Multipliziere das mit der Anzahl der Plattformen. Und zahl dann weiter, für immer.
Die Veröffentlichungsregeln
Über die reine Zustellung hinaus will der Nutzer eigentlich, dass nichts veröffentlicht wird, was abgelehnt würde. Das bedeutet, pro Plattform zu kodieren:
- Zeichenlimits
- Medienanzahl, -größen, -formate, -dauer, -seitenverhältnisse
- Welche Beitragstypen Medien erfordern
- Welche Formate überhaupt existieren
Und die Validierung bei der Erstellung durchzuführen statt erst bei der Veröffentlichung, denn ein Fehler beim Veröffentlichen ist einer, den der Nutzer erst bemerkt, nachdem der Moment vorbei ist.
Baue ihn selbst, wenn
- Du dauerhaft auf genau eine Plattform veröffentlichst
- Veröffentlichung dein Produkt und dein Unterscheidungsmerkmal ist
- Du weit über die Veröffentlichung hinausgehende Tiefe brauchst, wie Anzeigenverwaltung
Baue ihn nicht, wenn
Veröffentlichung ein Feature von etwas anderem ist, das du baust, und drei oder mehr Plattformen erreicht. Die Kosten liegen nicht im Bau, sondern in der Wartung, und die Wartung skaliert mit der Anzahl der Plattformen, während dein Team das nicht tut.
Die Alternative
Eine Integration, bei der die Plattform-Fluktuation das Problem von jemand anderem ist.
- Basis-URL:
https://app.bulkpublish.com - Auth: API-Key oder OAuth 2.1, wenn du im Namen deiner Nutzer handelst
- Umfang: 59 dokumentierte Endpunkte
- Plattformen: 15
- Validierung: Limits werden bei der Erstellung geprüft, nicht erst bei der Veröffentlichung
- SDKs: Node und Python, plus eine Postman-Collection und ein MCP-Server
| Free | Pro | Business | |
|---|---|---|---|
| API-Requests/Tag | 30 | 5.000 | 50.000 |
| API-Keys | 1 | 5 | 10 |
Die Kurzfassung
Die Warteschlange ist ein Wochenendprojekt. Die Zustände, die Zeitzonen und je ein OAuth-Flow plus ein Refresh-Job plus eine Medien-Pipeline pro Plattform sind das eigentliche Projekt, und die Plattform-Fluktuation sorgt dafür, dass es nie fertig wird. Baue ihn, wenn Veröffentlichung dein Produkt ist oder du dauerhaft auf einer Plattform bleibst. Andernfalls ist die Integration, die du nicht selbst wartest, mehr wert als die, die du wartest.