Sofort über eine API zu veröffentlichen, ist einfach. Planung ist, wo die interessanten Probleme liegen, denn ein geplanter Beitrag ist ein Versprechen über die Zukunft, und die Zukunft enthält Sommerzeit, Ausfälle und Beiträge, bei denen man es sich anders überlegt.
Zeitzonen: gib eine explizit an
Der häufigste Planungsfehler ist ein Beitrag, der zweimal im Jahr um eine Stunde abdriftet.
Eine geplante Zeit braucht zwei Dinge: den Zeitpunkt, als ISO-8601-Zeitstempel, und die Zone, in der er ausgedrückt wurde, als IANA-Name wie America/New_York.
await bp.posts.create({
content: 'Morning update.',
channels: [{ channelId: 1, platform: 'linkedin' }],
status: 'scheduled',
scheduledAt: '2026-04-10T14:00:00Z',
timezone: 'America/New_York',
});Nur einen UTC-Zeitpunkt zu speichern, ist für einen einmaligen Beitrag in Ordnung. Es ist falsch für alles Wiederkehrende, denn “jeden Wochentag um 9 Uhr lokal” ist vor und nach einer Zeitumstellung ein anderer UTC-Zeitpunkt. Die Zone ist es, was das richtig macht.
Speicher nie einen rohen Versatz wie -05:00 als Ersatz für eine Zone. Versätze ändern sich, Zonen nicht.
Mehr als zwei Zustände modellieren
Ein Beitrag ist nicht nur geplant oder veröffentlicht. Bau für mindestens:
- draft, erstellt, aber nicht eingereiht
- scheduled, für eine Zeit eingereiht
- processing, an die Plattform gesendet, Ausgang unbekannt
- published, bestätigt live
- failed, mit einem Grund
- partial, an manche Ziele veröffentlicht und an andere nicht
Die zwei, die man vergisst, sind processing und partial.
processing existiert, weil mehrere Plattformen einen Beitrag annehmen und ihn asynchron veröffentlichen. Ein 200 ist keine Veröffentlichung, und das tatsächliche Ergebnis kommt später.
partial existiert, weil ein Beitrag meist mehrere Plattformen anvisiert. Gelingen drei und schlägt einer fehl, stimmt weder “published” noch “failed”, und es in eines von beiden zu zwingen, erzeugt eine UI, die den Nutzer belügt.
Was passiert, wenn eine Plattform ausfällt
Gestalte dafür, denn es passiert.
Vorübergehende Fehler sollten mit Backoff wiederholt werden. Eine Plattform, die zwei Minuten lang 503 zurückgibt, sollte nicht den Beitrag verlieren.
Wiederholungen müssen sicher sein. Ein Create, das in ein Timeout lief, kann erfolgreich gewesen sein. Blindes Wiederholen dupliziert den Beitrag, was schlimmer ist als der ursprüngliche Fehler. Prüfe vor dem Wiederholen.
Dauerhafte Fehler sollten gar nicht wiederholt werden. Ein abgelaufenes Token oder eine ungültige Bildunterschrift repariert sich nicht von selbst, und ein Wiederholungsversuch verbrennt nur Kontingent und verzögert die Benachrichtigung.
Jemand muss informiert werden. Ein fehlgeschlagener geplanter Beitrag um 3 Uhr nachts bleibt still, wenn du ihn nicht laut gemacht hast. Webhooks sind der richtige Mechanismus.
Bearbeiten und Abbrechen
Ein geplanter Beitrag ist ein Versprechen, das du vielleicht brechen musst. Deine Integration sollte das Ändern der Zeit, das Bearbeiten des Inhalts und das vollständige Abbrechen unterstützen.
Beachte, dass Plattformen sich darin unterscheiden, ob sie das erlauben, sobald sie den Beitrag halten, was ein Grund ist, warum Planung in deiner eigenen Schicht und Einreichung im letzten Moment sich besser verhält, als der Plattform einen zukunftsdatierten Beitrag zu übergeben.
Warteschlangenplätze versus explizite Zeiten
Zwei Planungsmodelle, und beide haben ihren Platz.
Explizite Zeiten sind, was du willst, wenn ein Beitrag zu einem Moment landen muss: ein Launch, ein Event, eine koordinierte Ankündigung.
Warteschlangenplätze sind, was du für ein gleichmäßiges Tröpfeln willst. Du definierst eine Veröffentlichungskadenz, und der nächste Beitrag nimmt den nächsten freien Platz, sodass du nicht für jeden Beitrag in einem Stapel Zeitstempel wählst.
Für Bulk-Arbeit ist Zweiteres deutlich weniger mühsam, und es ist das Modell, das “dreißig Beiträge einreihen” zu einer sinnvollen Operation macht statt zu dreißig Entscheidungen.
Wiederkehrende Zeitpläne
Zu unterscheiden von einem geplanten Beitrag. Ein wiederkehrender Zeitplan ist eine Regel, die weiter Beiträge nach einer Häufigkeit erzeugt: täglich, wöchentlich, zweiwöchentlich oder monatlich.
Zwei Dinge, für die man gestalten sollte. Die Zone zählt hier noch mehr, aus dem oben genannten Sommerzeit-Grund. Und Medien, die an einen wiederkehrenden Beitrag angehängt sind, müssen aufbewahrt statt nach der Veröffentlichung bereinigt werden, denn der Zeitplan braucht sie beim nächsten Mal wieder.
Tarif-Limits
| Free | Pro | Business | |
|---|---|---|---|
| API-Anfragen/Tag | 30 | 5.000 | 50.000 |
| Beiträge | 3/Tag | 30/Tag | Unbegrenzt |
| Wiederkehrende Zeitpläne | Keine | 10 | Unbegrenzt |
Die Kurzfassung
Gib zu jedem geplanten Zeitstempel eine IANA-Zeitzone mit an, besonders bei allem Wiederkehrenden. Modelliere processing und partial als echte Zustände, denn asynchrones Veröffentlichen und plattformübergreifende Beiträge lassen beide wirklich vorkommen. Wiederhole vorübergehende Fehler mit Backoff, wiederhole ein Create nie blind, und nutz Webhooks, damit ein Fehlschlag um 3 Uhr nachts nicht still bleibt.