Feedback zu meiner n8n-Architektur für automatisiertes Instagram-Posting

Hilf mir, meinen Workflow zu erstellen
1

Hallo zusammen,

Ich entwerfe einen automatisierten Instagram-Posting-Workflow für ein Real-Estate-Marketing-Projekt und würde mich über Feedback von Personen freuen, die ähnliche Workflows mit n8n erstellt haben.

Aktuelle Architektur:

Obsidian Brain (Single Source of Truth)
↓
Google Drive
↓
n8n
↓
Instagram-bereite Notizen lesen
↓
Markdown analysieren
↓
AI generiert Caption + Hashtags + CTA
↓
Slack-Genehmigung
↓
Genehmigt?
├── Nein → Bearbeiten / Neu generieren
└── Ja
↓
Instagram Graph API
↓
Auf Instagram veröffentlichen
↓
Obsidian Brain aktualisieren

Das Ziel ist es, das Obsidian Brain als Single Source of Truth zu bewahren und sicherzustellen, dass jeder Instagram-Post vor der automatischen Veröffentlichung in Slack überprüft wird.

Ich würde mich über dein Feedback zu folgenden Punkten freuen:

• Macht diese Architektur Sinn?
• Würdest du etwas ändern oder vereinfachen?
• Gibt es Engpässe oder häufige Fallstricke?
• Gibt es eine bessere Möglichkeit, diesen Workflow in n8n zu strukturieren?

Danke im Voraus!

2

Hey Glven!
Der Ablauf macht für mich Sinn, aber ich würde noch ein paar Dinge überprüfen:
Wenn Obsidian deine einzige Quelle der Wahrheit ist, lass nicht zu, dass Slack zu einem versteckten Ort wird, wo Statusupdates verloren gehen: Ich würde sicherstellen, dass alle wichtigen Details direkt zurück in Obsidian gespeichert werden, damit du es als einzige Quelle der Wahrheit für alles behalten kannst.
Auch vor der Veröffentlichung würde ich eine weitere Überprüfung auf doppelte Genehmigungen/Wiederholungen durchführen, da Slack und API-Wiederholungen manchmal mehr als einmal ausgelöst werden können. Eine eindeutige Post-/Content-ID und eine Idempotenzprüfung könnten dich vor versehentlichen Duplikaten bewahren.
Zum Abschluss könnte auch die „Nein"-Option in „Manuell bearbeiten

3

Die Form ist solide und Lupels Punkte zum Zurückschreiben des Status in Obsidian und zur Vermeidung doppelter Genehmigungen sind die richtigen. Es gibt drei Dinge beim Veröffentlichungsschritt, die dir Probleme bereiten werden, denn Instagram funktioniert nicht so, wie ein einzelner Publish-Knoten vermuten lässt.

Das Veröffentlichen besteht aus zwei API-Aufrufen, nicht einem. Du sendest POST an /media, um einen Container zu erstellen und erhältst eine creation_id zurück, dann sendest du POST an /media_publish mit dieser ID. Der Container ist nicht sofort nach der Erstellung einsatzbereit, daher musst du zwischen den beiden Aufrufen den Container mit fields=status_code abfragen, bis er FINISHED zurückgibt. Das Veröffentlichen während er noch IN_PROGRESS ist, schlägt fehl, und bei allem außer einem kleinen Bild ist diese Verzögerung groß genug, um Auswirkungen zu haben.

Das führt zu einem Ordering-Problem, das spezifisch für dein Design ist. Container verfallen nach 24 Stunden. Wenn du den Container vor der Slack-Genehmigung erstellst und die Genehmigung über ein Wochenende sitzt oder jemand weg ist, schlägt die Veröffentlichung mit einem abgelaufenen Container fehl, obwohl alles ordnungsgemäß genehmigt wurde. Erstelle den Container nach der eingegangenen Genehmigung, nicht davor. Der Genehmigungsschritt ist menschlich geprägt und der Container nicht.

Das, das die meisten Leute mit deinem genauen Stack erwischt: Instagram ruft das Bild von einem öffentlichen URL-Server serverseitig ab. Ein normaler Google-Drive-Freigabe-Link gibt keine Image-Bytes zurück, sondern eine HTML-Seite, daher schlägt die Container-Erstellung fehl oder erzeugt nichts Brauchbares. Du brauchst einen direkten Link, der mit der tatsächlichen Datei und dem korrekten Content-Type antwortet. Es lohnt sich, diesen einzelnen Aufruf zu testen, bevor du den Rest verdrahtst, denn der Fehler, den er erzeugt, ist nicht offensichtlich.

Es ist auch gut zu wissen, bevor du skalierst: Das Konto ist auf 50 veröffentlichte Beiträge in 24 Stunden begrenzt, und Obsidian-Synchronisierung über Drive ist schließlich konsistent, sodass eine Notiz, die gelesen wird, sobald sie ankommt, eine teilweise geschriebene Datei sein kann. Eine kurze Verzögerung oder eine Vollständigkeitsprüfung vor dem Parsen erspart dir später eine verwirrende Debugging-Sitzung.

4

Der zweistufige Graph-API-Prozess ist der Teil, der normalerweise problematisch wird, besonders wenn die Slack-Genehmigung dazwischengeschaltet ist und der Container ablaufen kann. Der Hinweis zur Reihenfolge oben ist der wichtige.

Wenn du diese Leitungen nicht warten möchtest, gibt es einen n8n-Community-Node, der nach dem Hochladen von Medien auf Instagram (und TikTok/YouTube/X) postet. Hast du es schon mit Chat33 versucht? Könnte einfacher sein, als die Graph-Aufrufe selbst zu verwalten.

5

Wir betreiben einen eigenen Scheduler auf unserer Website, also all das sind Dinge, die bei uns kaputtgegangen sind.

Das Token würde ich zuerst beheben, denn es passiert an dem Tag, an dem niemand hinschaut. Wir haben ein System gebaut, das den Schlüssel selbst am Leben erhält, sodass der Workflow nie auf einen toten trifft.

Das, was dir Zeit kostet, ist Video. Mit einem einfachen Bild gehen die zwei Aufrufe problemlos durch und es sieht gelöst aus. Steck ein Video rein und Instagram nimmt die Datei noch auf, wenn dein Publish-Aufruf kommt, also ist der Container nicht bereit. Die Abfolge muss sein: Upload öffnen, auf die Meldung des Containers warten, dass er bereit ist, dann publishen.

Unser läuft auf Cron, also verteilen wir das über mehrere Durchläufe, statt darin zu schlafen. Erster Durchlauf bereitet vor und öffnet, zweiter Durchlauf publisht, und ein dritter Durchlauf ist für den Fall, dass das Medium immer noch nicht bereit ist. Dieser dritte ist das, was die Fehler beendet hat, die niemand sah.

Wir sind zuerst auf Reels getroffen. Carousels funktionieren eine Zeit lang weiter, wahrscheinlich weil die Bilder leicht genug sind, um rechtzeitig anzukommen, also habe ich sie in Ruhe gelassen, und dann fingen sie auch an zu scheitern und ich musste das Gleiche für sie bauen.

Bei den 50 pro rollendes 24-Stunden-Fenster: das sitzt auf dem Instagram-Konto, also nimmt es kein Tool weg. Die Queue ist eine andere Sache. Es gibt keinen Grund, warum ein Scheduler einschränken sollte, wie weit du voraus planen kannst, und unser wird einen Slot drei Jahre im Voraus halten und ihn dann ausführen. Bei Listings, die ein Startdatum haben, ist das das Wertvolle.

Zu deinem Slack-Schritt: Den Container nach der Genehmigung zu erstellen, ist der richtige Weg, aber wenn derselbe Durchlauf direkt danach publisht, wird dich Video genau da beißen. Und wenn deine Listings heute Fotos sind, zeigt sich nichts davon, bis der erste Video-Tour reinkommt.

6

Der Obsidian → Markdown → KI-Caption-Flow macht Sinn, aber ich denke, dein Engpass wird die Slack-Genehmigungsschleife sein, nicht das Posten.

Ein paar Dinge, die es sich lohnt zu testen, bevor du das hochfahrst:

  • Füge ein Timeout im sendAndWait-Schritt hinzu, damit Elemente nicht im Obsidian-Limbo steckenbleiben, wenn niemand einen Tag lang genehmigt
  • Versioniere deine KI-generierten Captions, anstatt sie beim Regenerieren zu überschreiben – Compliance-Reviewer für Immobilien möchten normalerweise sehen, was sich geändert hat
  • Teste die Instagram Graph API Rate Limits frühzeitig, sie sind strenger als die Leute erwarten, sobald du täglich über mehrere Angebote postest

Eine Sache, die ich strukturell ändern würde: Markdown parsen und die Caption parallel generieren statt sequenziell, das reduziert deine Laufzeit und der KI-Schritt hängt in den meisten Fällen nicht wirklich davon ab, dass das Parsen zuerst fertig ist

7

Mir gefällt die Gesamtform, besonders die Beibehaltung eines menschlichen Genehmigungsschritts vor der Veröffentlichung.

Das Wichtigste, das ich explizit machen würde, ist das Statusmodell. Jeder Beitrag sollte eine stabile Inhalts-ID und einen Status wie Entwurf, Genehmigung ausstehend, Bearbeitung erforderlich, genehmigt, Container erstellt, veröffentlicht, fehlgeschlagen haben. Auf diese Weise ist Slack nur eine Genehmigungsoberfläche, nicht der Ort, an dem der Workflow-Status heimlich lebt.

Ich würde auch die endgültig genehmigte Bildunterschrift/Medien-URL vor der Veröffentlichung wieder in Obsidian speichern. Wenn der Beitrag später fehlschlägt, haben Sie immer noch das exakte genehmigte Artefakt, anstatt zu versuchen, es aus der Slack-Historie zu rekonstruieren.