Auf sozialen Plattformen von Node aus zu veröffentlichen bedeutet normalerweise einen OAuth-Ablauf, eine Medien-Pipeline und ein Publishing-Modell pro Plattform, die sich alle ständig ändern. Das hier erledigt es über einen einzigen Client.
Installieren und authentifizieren
npm install bulkpublish
import { BulkPublish } from 'bulkpublish';
const bp = new BulkPublish({ apiKey: process.env.BULKPUBLISH_API_KEY });
Hol dir einen Key aus den Entwicklereinstellungen deines Kontos. Bewahr ihn in einer Umgebungsvariable auf, nicht im Quellcode.
Einen Entwurf erstellen
Fang hier an, statt sofort zu veröffentlichen. Ein Entwurf ist in der App sichtbar, du kannst also genau sehen, was dein Code erzeugt hat, bevor irgendetwas ein Publikum erreicht.
const post = await bp.posts.create({
content: 'Check out our latest update!',
channels: [
{ channelId: 1, platform: 'facebook' },
{ channelId: 2, platform: 'x' },
{ channelId: 3, platform: 'linkedin' },
],
status: 'draft',
});
Jeder Kanal ist ein Objekt mit einer channelId und einer platform. So findest du deine:
const channels = await bp.channels.list();
Hardcode keine Kanal-IDs aus einem Einmal-Skript in irgendetwas Langlebiges. Schlag sie nach, oder speichere sie in der Konfiguration, wo sie ohne Deploy geändert werden können.
Einen planen
const post = await bp.posts.create({
content: 'Check out our new feature!',
channels: [{ channelId: 1, platform: 'instagram' }],
mediaFiles: [uploadedFile.id],
postFormat: 'reel',
status: 'scheduled',
scheduledAt: '2026-04-10T14:00:00Z',
timezone: 'America/New_York',
});
Zwei Felder, die es sich lohnt, zusammen zu verstehen. scheduledAt ist ein ISO-8601-Zeitstempel, und timezone ist ein IANA-Zonenname. Die Zeitzone explizit anzugeben ist es, was wiederkehrende Logik über Sommerzeit-Wechsel hinweg vernünftig verhalten lässt, statt zweimal im Jahr um eine Stunde zu driften.
Medien
Medien werden zuerst hochgeladen und dann beim Erstellen des Beitrags per ID referenziert:
const file = await bp.media.upload(/* … */);
await bp.posts.create({
content: 'New drop.',
mediaFiles: [file.id],
channels: [{ channelId: 1, platform: 'instagram' }],
status: 'scheduled',
scheduledAt: '2026-04-10T14:00:00Z',
});
Die Medienregeln jeder Plattform unterscheiden sich, und sie werden geprüft, bevor der Beitrag eingereiht wird, statt beim Veröffentlichen. Das ist das Verhalten, das du dir von einem Skript wünschst: eine Ablehnung, die du jetzt abfangen und protokollieren kannst, kein stiller Ausfall um 9 Uhr morgen früh.
Die verfügbaren Ressourcen
Der Client stellt Posts, Channels, Channel Sets, Media, Labels, Schedules, RSS-Feeds, Analytics und Platforms bereit. Ein Skript kann also mehr als erstellen: nachsehen, was eingereiht ist, das Kontingent prüfen, Metriken nach dem Veröffentlichen abrufen.
Was es sich lohnt, richtig zu machen
Nie direkt in der ersten Version veröffentlichen. Erstelle Entwürfe, sieh sie dir an, wechsle dann zu scheduled. Das kostet nichts und fängt Formatierungsprobleme ab, die im Code unsichtbar sind.
Ratenlimits handhaben. Das Kontingent deines Plans ist eine echte Obergrenze:
| Free | Pro | Business | |
|---|---|---|---|
| API-Anfragen/Tag | 30 | 5.000 | 50.000 |
| API-Keys | 1 | 5 | 10 |
| Die 30 am Tag bei Free sind zum Ausprobieren der API bemessen, nicht zum Betreiben von irgendetwas. Ein Skript in einer Retry-Schleife schöpft das in Sekunden aus. |
Erzeuge keine eigenen Plan-Fakten. Schreibt dein Skript Beitragstext, halte Produktzahlen daraus fern. Alles Faktische sollte aus einer Quelle kommen statt aus einer Vorlage, die nach der nächsten Preisänderung falsch sein wird.
Die Kurzfassung
npm install bulkpublish, einen Client mit deinem API-Key erstellen, bp.posts.create mit Content und Channels aufrufen. Fang mit Entwürfen an, schlag Kanal-IDs nach statt sie zu hardcoden, gib bei allem Geplanten eine Zeitzone an.