Dein Produkt muss auf sozialen Plattformen posten. Irgendwann fragt jemand, ob man die Plattformen direkt integriert oder eine Publishing-API nutzt, und die ehrliche Antwort hängt von Dingen ab, die in der ersten Schätzung nicht auftauchen.
Die Schätzung, die immer falsch ist
Die erste Schätzung gilt dem Idealfall auf einer Plattform: einen Token holen, etwas Text posten, fertig. Dieser Teil ist tatsächlich ein paar Tage Arbeit.
Hier ist, was die Schätzung pro Plattform auslässt.
Token-Lebenszyklus. Tokens laufen ab. Manche in Wochen. Sie zu erneuern ist ein geplanter Job, und wenn er fehlschlägt, geschieht das still: Die Verbindung ist tot, Veröffentlichen scheitert, und niemand merkt es, bis ein Nutzer sich beschwert. Du brauchst Erkennung und einen Wiederverbindungs-Ablauf.
Medien. Jede Plattform nimmt Medien anders entgegen. Manche holen eine URL. Manche wollen einen fortsetzbaren, in Blöcke geteilten Upload. Manche wollen bestimmte Abmessungen, Längen oder Codecs und lehnen alles andere ab. Du wirst hosten und möglicherweise transkodieren müssen.
Asynchrones Veröffentlichen. Auf mehreren Plattformen ist die Annahme deines Beitrags nicht das Veröffentlichen. Du bekommst eine ID und fragst den Status ab, und der eventuelle Ausfall kommt lange, nachdem deine Anfrage 200 zurückgegeben hat. Dein Datenmodell braucht einen “wir glauben, das wird veröffentlicht”-Zustand, der nicht offensichtlich ist, bis man darüber stolpert.
Ratenlimits. Unterschiedliche Fenster, unterschiedliche Header, unterschiedliches Verhalten bei Überschreitung. Du brauchst Warteschlangen und Backoff pro Plattform.
Genehmigung. Mehrere Plattformen sperren Publishing hinter einem Review-Prozess, mit Anforderungen an deine App, deine Datenschutzrichtlinie und manchmal ein Demo-Video. Das ist Kalenderzeit, die du nicht verdichten kannst, und sie kann abgelehnt werden.
Laufende Änderungen. API-Versionen werden nach dem Zeitplan der Plattform veraltet. Felder werden umbenannt. Berechtigungen werden verschärft. Jedes davon ist ungeplante Arbeit mit einer Frist, die du nicht gesetzt hast.
Der letzte Punkt ist der, der es entscheidet. Bauen ist kein Projekt, das endet, sondern eine dauerhafte Wartungsverpflichtung, die mit jeder Plattform wächst.
Der eigentliche Vergleich
Nicht “ein paar Tage pro Plattform” gegen ein Abonnement. Es ist:
| Bauen | Kaufen | |
|---|---|---|
| Anfangsaufwand | Wochen pro Plattform, plus Genehmigungszeit, die du nicht kontrollierst | Eine Integration |
| Laufend | Plattformänderungen, Token-Refresh-Ausfälle, Medien-Pipeline | Vom Anbieter übernommen |
| Plattform hinzufügen | Eine weitere vollständige Integration | Ein Parameter |
| Fehlerfälle | Deine, zu erkennen, zu debuggen und zu erklären | Vom Anbieter aufgezeigt |
| Genehmigung | Deine, pro Plattform zu erhalten und zu pflegen | Bereits vorhanden |
Wann Bauen richtig ist
Drei Fälle, in denen es tatsächlich stimmt.
Eine Plattform, dauerhaft. Veröffentlichst du auf genau einem Netzwerk, und das wird sich nicht ändern, ist eine direkte Integration einfacher und entfernt eine Abhängigkeit.
Publishing ist dein Produkt. Ist die Publishing-Schicht dein Unterscheidungsmerkmal, ist das, was du besitzen solltest.
Du brauchst Tiefe über Publishing hinaus. Anzeigenverwaltung, vollständige Kommentarmoderation, tiefgehende Analysen. Diese gehen über das hinaus, was eine Publishing-API abdeckt, und du landest ohnehin bei der eigenen API der Plattform.
Wann Kaufen richtig ist
Alles, das drei oder mehr Plattformen erreicht, wo Publishing eine Funktion ist statt das Produkt. Die Wartung ist die Kosten, nicht der Bau, und die Wartung skaliert mit der Plattformzahl, während dein Team es nicht tut.
Außerdem: alles mit einer Frist. Genehmigungsprozesse der Plattformen dauern, so lange sie dauern, und Kaufen bedeutet, dass jemand sie bereits durchlaufen hat.
Was du vor dem Kauf prüfen solltest
- Die unterstützte Plattformliste, konkret. Nicht “alle großen Netzwerke”
- Auth-Modell. Verbinden deine Nutzer ihre eigenen Konten, brauchst du OAuth, nicht nur einen API-Key
- Ratenlimits bei der Stufe, auf der du tatsächlich wärst
- Webhooks, damit du Ausfälle erfährst, ohne abzufragen
- Ob Validierung vor dem Veröffentlichen passiert. Eine überlange Bildunterschrift erst beim Veröffentlichen zu bemerken, bedeutet einen gescheiterten Beitrag
- Was passiert, wenn eine Plattform ausfällt. Das ist es, wofür du bezahlst
Die BulkPublish-API
- Basis-URL:
https://app.bulkpublish.com - Auth: API-Key für dein eigenes Konto, OAuth 2.1 für das Handeln im Auftrag anderer
- Umfang: 59 dokumentierte Endpunkte für Beiträge, Planung, Medien, Kanäle, Labels, Analysen, RSS-Feeds und Kontingente
- Plattformen: 15
| Free | Pro | Business | |
|---|---|---|---|
| API-Anfragen/Tag | 30 | 5.000 | 50.000 |
| API-Keys | 1 | 5 | 10 |
| Node- und Python-SDKs, eine Postman-Sammlung und ein MCP-Server für KI-Agenten. Die kostenlose Stufe ist für die Bewertung der API bemessen, nicht für Produktionstraffic. |
Die Kurzfassung
Die Bau-Schätzung liegt meist bei der ersten Plattform richtig und bei allem danach falsch, weil die Kosten Wartung sind, nicht Konstruktion. Bau selbst, wenn du für immer auf einer Plattform bist, wenn Publishing dein Produkt ist, oder wenn du Tiefe über Publishing hinaus brauchst. Sonst ist die Integration, die du nicht wartest, mehr wert als die, die du wartest.