Deine Nutzer erstellen etwas in deinem Produkt und verlassen es dann, um es woanders zu posten. Diese Lücke zu schließen, ist ein häufiger Feature-Wunsch, und die Form der Arbeit hängt fast vollständig von einer Entscheidung ab, die am Anfang getroffen wird.
Die Entscheidung: wessen Konto ist es?
Gehen Beiträge an deine eigenen Konten, reicht ein API-Schlüssel. Server-zu-Server, kein Einwilligungsablauf, das einfachste, was es gibt.
Gehen Beiträge an die Konten deiner Nutzer, brauchst du OAuth. Jeder Nutzer autorisiert deine App, und du bekommst ein begrenztes Token, das an den Arbeitsbereich gebunden ist, den er gewählt hat.
Bring das am Anfang in Ordnung. Produkte, die damit beginnen, Nutzer um das Einfügen eines API-Schlüssels zu bitten, migrieren später zu OAuth, und in der Zwischenzeit haben sie den Nutzern eine Angewohnheit beigebracht, die für beide Seiten schlecht ist: einen langlebigen Zugangsdatensatz mit breitem Zugriff in ein Drittanbieterprodukt einzufügen.
Was du sonst bauen müsstest
Der Grund, eine Publishing-API zu nutzen statt Plattformen direkt zu integrieren, ist, dass direkte Integration ein Projekt pro Plattform ist, das nie fertig wird:
- Ein separater OAuth-Ablauf pro Plattform, mit unterschiedlichen Scopes und Token-Lebensdauern
- Ein Refresh-Job pro Plattform, der still fehlschlägt und die Veröffentlichung mitreißt
- Eine separate Medien-Pipeline pro Plattform, mit unterschiedlichen Upload-Modellen
- Asynchrones Veröffentlichen bei mehreren, wo ein 200 nicht “veröffentlicht” bedeutet
- Ein separates Ratenlimit pro Plattform
- App-Review bei mehreren, was Kalenderzeit ist, die du nicht kontrollierst und die verweigert werden kann
- Laufende Breaking Changes nach dem eigenen Zeitplan jeder Plattform
Für ein SaaS, bei dem Veröffentlichung ein Feature statt das Produkt ist, ist das eine dauerhafte Wartungsverpflichtung an etwas, das nicht dein Unterscheidungsmerkmal ist.
Was du trotzdem bauen musst
Eine Publishing-API zu nutzen, entfernt nicht die ganze Arbeit. Du brauchst weiterhin:
Eine Verbindungs-UI. Irgendwo verbinden Nutzer ihre Konten und sehen den Status der Verbindung.
Einen sichtbaren Fehlerzustand. Verbindungen brechen. Nutzer müssen das sehen und beheben können, und es muss ein Zustand in deinem Produkt sein, statt ein Fehler, den du schluckst.
Komposition, in den Begriffen deines Produkts. Die API nimmt Inhalt und Kanäle entgegen. Was deine Nutzer tatsächlich tun und wie sich das auf einen Beitrag abbildet, ist deine Sache.
Fehlerbehandlung. Etwas wird nicht veröffentlicht werden können. Entscheide jetzt, ob der Nutzer es von dir erfährt oder aus dem Fehlen eines Beitrags.
Was bei der Wahl zu prüfen ist
| Anforderung | Warum |
|---|---|
| OAuth mit granularen Scopes | Multi-User-Produkte brauchen es, und enge Scopes begrenzen den Schadensradius |
| Die konkrete Plattformliste | Nicht “alle großen Netzwerke” |
| Validierung beim Erstellen | Damit eine zu lange Bildunterschrift dort scheitert, wo du es dem Nutzer zeigen kannst |
| Ratenlimits in deiner Stufe | Die Zahl, die entscheidet, ob es mit dir skaliert |
| Strukturierte Fehler | Damit du etwas Nützliches zeigen kannst statt “Veröffentlichung fehlgeschlagen” |
BulkPublish dafür
- Auth: OAuth 2.1 zum Handeln im Namen der Konten deiner Nutzer, API-Schlüssel für deine eigenen
- OAuth-Details: PKCE (S256) erforderlich,
scopeerforderlich ohne impliziten Standard, einmal nutzbare Autorisierungscodes, rotierende Refresh-Token, Token übergeben alsBearer bpat_... - Scopes:
posts:read,posts:write,media:read,media:write,analytics:read,channels:read,full - Umfang: 59 dokumentierte Endpunkte
- Plattformen: 15
Eine Grenze, um die herum du gestalten solltest: OAuth-Token erreichen Beiträge, Zeitpläne, Labels, Medien, Analysen, Kontingentnutzung und schreibgeschützte Kanaldaten. Kontoverwaltung, also Team, Organisationen, Abrechnung, Guthabenkäufe, API-Schlüssel und OAuth-App-Verwaltung, liefert für jedes OAuth-Token einschließlich full einen 403, weil diese Aktionen die Verbindungstrennung eines Nutzers zu deiner App überdauern würden. Dafür braucht es einen API-Schlüssel.
Besser, das jetzt zu wissen, als es als unerklärten 403 in der Produktion zu finden.
| Free | Pro | Business | |
|---|---|---|---|
| API-Anfragen/Tag | 30 | 5.000 | 50.000 |
| API-Schlüssel | 1 | 5 | 10 |
Die Kurzfassung
Entscheide zuerst, ob du an deine eigenen Konten oder an die deiner Nutzer veröffentlichst. Sind es die der Nutzer, nutz OAuth von Tag eins statt später zu migrieren. Plattformen direkt zu integrieren, ist eine dauerhafte Wartungsverpflichtung an etwas, das nicht dein Produkt ist, und die Teile, die du trotzdem bauen musst, sind die Verbindungs-UI, ein sichtbarer Fehlerzustand und den Nutzern zu sagen, wenn etwas fehlgeschlagen ist.