Beiträge per API planen: X, LinkedIn und Bluesky in einem Aufruf

Wenn du Planung in ein Produkt einbaust, etwa ein CMS, ein Newsletter-Tool oder einen KI-Assistenten für Inhalte, merkst du schnell: Jedes Netzwerk macht es anders. Manche können nativ nur eingeschränkt planen, manche gar nicht, und jedes hat eigene Auth, Limits und Fehlerbilder.

Der übliche Weg ist, den Beitrag zu speichern, zum richtigen Zeitpunkt einen Job laufen zu lassen und jede API aufzurufen. Damit gehören dir ein Scheduler, die Wiederholungen, der Token-Refresh und die Fehlermeldungen, die deine Nutzer sehen.

Hier ist der kürzere Weg.

Die Fassung mit einer Anfrage

curl -X POST https://hapi.tools/v1/posts \
  -H "Authorization: Bearer $HAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: campaign-42-post-1" \
  -d '{
    "content": "Our winter release is live. Here is what is new 👇",
    "platforms": ["x", "linkedin", "bluesky"],
    "scheduledAt": "2026-12-01T09:00:00-03:00",
    "timezone": "America/Sao_Paulo"
  }'

Was dann passiert:

1. Hapi prüft den Inhalt gegen die echten Limits jeder Plattform, bevor es ihn annimmt. Ist der Text für Bluesky oder X zu lang, bekommst du den Validierungsfehler sofort, nicht einen fehlgeschlagenen Beitrag um 9 Uhr.
2. Der Beitrag wird für genau diesen Zeitpunkt als geplant gespeichert, gekennzeichnet mit der Zeitzone, in der er geplant wurde.
3. Zum Veröffentlichungszeitpunkt erneuert Hapi bei Bedarf die Tokens, veröffentlicht auf jedem Konto und speichert ein Ergebnis pro Konto.
4. Dein Webhook-Endpoint bekommt für jedes Ergebnis ein signiertes Event post.published oder post.failed.

Zeitzonen, die nicht danebengehen

Schick scheduledAt immer als ISO-8601-Zeitstempel mit Offset (2026-12-01T09:00:00-03:00) oder in UTC (2026-12-01T12:00:00Z). Eine Zeit ohne Offset wird mit einem Validierungsfehler abgelehnt. So kann ein Beitrag nie zur falschen Stunde rausgehen, nur weil die Uhr des Servers anders geht. Ergänz eine IANA-timezone wie America/Sao_Paulo, damit festgehalten wird, welche Ortszeit du gemeint hast.

Tipp: Lass eine Datumsbibliothek den Offset ausrechnen, dann ist die Sommerzeit mit drin. Mit Luxon: DateTime.fromISO("2026-12-01T09:00", { zone: "America/Sao_Paulo" }).toISO() liefert 2026-12-01T09:00:00.000-03:00, und genau das nimmt Hapi an.

Unterschiedlicher Text pro Netzwerk

LinkedIn belohnt längere Beiträge, Bluesky hört bei 300 Zeichen auf, und X hat eigene Limits. Mit platformOptions passt du jeden Text in derselben Anfrage an:

"platformOptions": {
  "linkedin": { "content": "Our winter release is live.\n\nThree things our customers asked for most: ..." },
  "bluesky": { "content": "Winter release is live ❄️ hapi.tools/changelog" }
}

Mitbekommen, wenn etwas scheitert

In vielen selbst gebauten Systemen scheitern geplante Beiträge still. Hapi signiert jeden Webhook mit HMAC-SHA256 und wiederholt die Zustellung mit exponentiellem Backoff (bis zu 6 Versuche):

hapi-signature: t=1764590400,v1=5f2b...

Prüf die Signatur und sag deinem Nutzer sofort Bescheid: „Dein LinkedIn-Beitrag ist nicht rausgegangen, weil das Konto getrennt wurde. Neu verbinden?“

Neu planen oder löschen

Geplante Beiträge sind ganz normale Ressourcen. Ruf sie ab, aktualisiere scheduledAt oder lösch sie über /v1/posts/{id}. Im Hapi-Dashboard gibt es auch einen Drag-and-drop-Kalender, falls dein Team sie von Hand verschieben will.

Welche Plattformen live sind

Stand heute sind Planung und Veröffentlichen live auf X, LinkedIn, Bluesky, Telegram, Discord und Slack. Instagram, TikTok, YouTube, Threads, Facebook, Pinterest und weitere gibt es im Sandbox-Modus: dieselbe API, geprüft gegen die echten Plattform-Limits, mit simulierten Ergebnissen. Du kannst deine Oberfläche jetzt bauen und testen und umstellen, sobald sie live gehen.

Probier es aus

Erstelle einen kostenlosen Key und plane deinen ersten Beitrag →

15 Tage alles testen für 5 $. Growth: 25 Konten, 5.000 Beiträge im Monat und Webhooks für 49 $/Monat. Sieh dir die Preise an.