So bauen Sie einen Meta Muse Connector für X-Posts

Meta führt überhaupt keinen X-Connector, ein Meta Muse Connector für X-Posts ist also einer, den Sie in einer einzigen Nachricht selbst bauen. Muse schreibt seinen Client aus einer öffentlichen API-Spezifikation auf seiner Cloud-VM selbst, die Arbeit besteht damit aus einem Einfügetext, einem Token und einem Feldnamen, den der Agent falsch setzt, wenn ihm das niemand sagt. Dieses Feld ist twitterConnectionIds, und die AdaptlyPost-Spezifikation hat es am 20. September 2026 erneut bestätigt.

Die Kurzfassung: Geben Sie Muse die Spezifikation unter post.adaptlypost.com/post/api/v1/openapi.json, fügen Sie ein adaptly_-Token in die sichere Zugangsdaten-Abfrage ein und sagen Sie, dass das X-Feld twitterConnectionIds heißt und das Plattform-Enum TWITTER. Danach planen Sie Threads Satz für Satz.

Warum fehlt in Metas Liste ein Meta Muse Connector für X-Posts?

Stand 20. September 2026 veröffentlicht Meta außerhalb des Produkts kein Connector-Verzeichnis, und X taucht in keiner der vorhandenen Teillisten auf. Chief AI Officer Alexandr Wang hat am 8. September 2026 eine Aufstellung gepostet, die Gmail, Google Calendar, Outlook, Plaid, OpenTable, Google Docs, Spotify, Function Health, Withings, Tailscale und Peloton umfasst, dazu Facebook, Instagram, Threads und Messenger. Parallels Launch-Verzeichnis vom 14. September 2026 nennt wiederum einen teilweise anderen Satz, ergänzt Ticketmaster und Apple Health und lässt Outlook, Google Docs, Withings, Tailscale und Messenger weg. Keine der beiden Listen nennt X.

Darunter liegt eine zweite Schicht, die man als das benennen sollte, was sie ist: eine kommerzielle Tatsache. X gehört einem Meta-Konkurrenten, und Threads ist Metas eigenes Kurzform-Netzwerk, dasjenige, das sich automatisch mit Muse verbindet, wenn die Konten ein Accounts Center teilen. Stand 20. September 2026 hat Meta keinen Connector angekündigt, der in eine gegnerische Timeline veröffentlicht.

X läuft deshalb über einen Custom Connector, Metas dokumentierte Antwort für einen nicht gelisteten Dienst: Muse holt sich die API-Informationen und schreibt den Client selbst. Meta erklärt außerdem unmissverständlich, dass es Custom Connectors nicht prüft und auch nicht, wie sie Ihre Daten verwenden. Der vollständige Aufbau, der Zugangsdaten-Ablauf und die VM-Mechanik stehen im Leitfaden zum Connector. Dieser Beitrag ist die X-Hälfte.

Was füge ich in Muse ein, um den X-Connector zu bauen?

Der Einfügetext ist der des Leitfadens plus eine Zeile. Spec-URL, Aufbau-Briefing, Auth-Header und die Regel zur Zugangsdaten-Abfrage stehen alle im Leitfaden zum Connector. Der X-Zusatz ist die letzte Anweisung:

Build a custom connector for AdaptlyPost so you can post to X, following the
setup in the pillar paste.
 
Do not publish anything yet. Call GET /social-accounts, show me the X handle
you can post as, and confirm from the spec that the X field is
twitterConnectionIds and the platform enum value is TWITTER.

Warum steht in der AdaptlyPost-Spezifikation weiterhin twitterConnectionIds?

Das Feld heißt twitterConnectionIds, weil der Name vor der Umbenennung in der Spezifikation eingefroren wurde, und der Beitrag zur Grok-Bot-Vorlage erklärt, warum er geblieben ist. Für Muse zählt der engere Punkt: Ein Agent, der die Spezifikation liest, sendet das richtige Feld, ein Agent, der vom Markennamen her denkt, nicht. Die AdaptlyPost-Spezifikation wurde am 20. September 2026 erneut abgerufen, um das zu bestätigen: twitterConnectionIds steht im Request-Schema, das Plattform-Enum ist TWITTER, und xConnectionIds kommt im gesamten Dokument nicht vor.

Ein Agent, der vom Markennamen aus improvisiert, erfindet xConnectionIds. Die Spezifikation definiert kein solches Feld, nichts im Request zeigt damit auf eine X-Verbindung, und der Post geht ohne X-Ziel raus.

Kann Muse einen X-Thread planen?

Muse plant einen Thread als Abfolge zeitgesteuerter Posts über POST /social-posts/bulk, gestaffelt über scheduledAt. AdaptlyPost kennt kein Thread-Objekt, nichts verkettet die Antworten also für Sie. Sagen Sie das Muse vorab, denn ein Agent, den Sie um einen zwölfteiligen Thread bitten, beschreibt sonst ein Reply-Chaining, das er nicht leisten kann.

Der Bulk-Endpunkt nimmt 1 bis 100 Posts in einem Aufruf entgegen. platforms, timezone und die Arrays mit Verbindungs-IDs stehen einmal oben im Request, jeder Eintrag in posts trägt sein eigenes contentType, text und scheduledAt. Die Staffelung ist ohnehin das, was Sie wollten. Ein auf einmal abgeladener Thread liest sich wie ein Datendump, dieselben Posts im Abstand von zwei Minuten lesen sich wie ein Thread, der gerade geschrieben wird.

You:  Schedule a 4-part thread on the connector launch, from 9am,
      two minutes apart, X only.
 
Muse: POST /social-posts/bulk
        { platforms: ["TWITTER"],
          twitterConnectionIds: ["..."],
          timezone: "Europe/Kyiv",
          posts: [
            { contentType: "TEXT", text: "1/ ...", scheduledAt: "2026-09-22T09:00:00" },
            { contentType: "TEXT", text: "2/ ...", scheduledAt: "2026-09-22T09:02:00" },
            { contentType: "TEXT", text: "3/ ...", scheduledAt: "2026-09-22T09:04:00" },
            { contentType: "TEXT", text: "4/ ...", scheduledAt: "2026-09-22T09:06:00" } ] }

Ein Muse-Detail gilt hier und bei anderen Agenten nicht. Sentinel, die Komponente, die jeden ausgehenden Request der VM autorisiert, legt eine offene Freigabe an und stoppt die Ausführung, sobald es Sie braucht. Metas Freigabe-Abfrage bietet Einmal erlauben, Für diese Aufgabe erlauben, Für diese Seite erlauben, Immer erlauben und Ablehnen. Bei einem Thread ist Für diese Aufgabe erlauben die Option, bei der Sie nicht viermal tippen.

Wie teilen sich X und Bluesky einen Aufruf?

Stand 20. September 2026 definiert die Spezifikation plattformspezifische Konfigurationsobjekte für genau fünf Netzwerke: Pinterest, TikTok, Instagram, Facebook und YouTube. X, Bluesky, LinkedIn und Threads nehmen ein Array mit Verbindungs-IDs, Text und optionale Medien entgegen, sonst nichts. X nimmt twitterConnectionIds, Bluesky nimmt blueskyConnectionIds, beide in einen Request zu packen fügt also zwei Arrays hinzu und keinen Konfigurationsblock.

Nutzen Sie platformTexts statt eines gemeinsamen Strings, wenn Sie auf beiden gleichzeitig veröffentlichen. Jeder Eintrag ist eine Plattform und ein Text, dieselbe Idee bekommt also eine für jede Timeline geschriebene Fassung statt einer Bildunterschrift, die auf das engere der beiden Limits gestutzt ist. AdaptlyPost setzt in der Spezifikation keine Maximallänge für text, jedes Netzwerk wendet also sein eigenes Limit auf den Text an, den es bekommt.

Was geht speziell auf X kaputt?

Eine abgelaufene oder widerrufene X-Verbindung scheitert beim Veröffentlichen, nicht bei der Planung. Ein Thread, der für nächsten Dienstag gebucht ist, wird heute angenommen, die Verbindung erlischt in der Zwischenzeit, und der Post scheitert am Tag selbst, ohne dass die ursprüngliche Antwort davor gewarnt hätte. GET /social-posts/{id}/results meldet das Ergebnis pro Plattform, und POST /social-posts/{id}/retry wiederholt nur die Fehlschläge, sobald Sie die Verbindung wiederhergestellt haben.

Muse verschärft das, wenn Sie es lassen. Der Connector meldet, was der Planungsaufruf zurückgegeben hat, Muse sagt Ihnen also, der Thread sei gebucht, und hält die Aufgabe für erledigt. Nehmen Sie den Results-Aufruf in den gespeicherten Skill auf, damit die Ergebniskontrolle Teil des Veröffentlichens ist und nicht etwas, woran Sie denken müssen.

Zwei weitere Punkte, beide nicht X-exklusiv, aber hier schärfer. Medien brauchen den Umlauf über POST /upload-urls vor POST /social-posts, und X-Video geht über eine Sequenz aus Initialize, Append und Finalize hoch, die länger dauert als ein Bild. AdaptlyPost zählt eigene Rate Limits pro API-Key und gibt sie bei jeder Antwort als RateLimit-Limit, RateLimit-Remaining und RateLimit-Reset zurück, bei einem 429 zusätzlich Retry-After. Sagen Sie Muse, es soll diese Header zwischen Bulk-Aufrufen lesen, statt einen Stapel nach Gefühl zu takten.

Häufig gestellte Fragen

Kann Muse ganz ohne Connector auf X posten?

Muse kann die X-Web-App mit seinem Browser-Sub-Agenten bedienen, der einen Snapshot des Accessibility-Baums liest statt des rohen DOM und kein JavaScript in der Seite ausführen kann. Das funktioniert, bis ein Button umzieht. Es gibt keinen plattformspezifischen Fehler, gegen den sich ein Retry richten könnte, und keine Planung, ein Connector gegen eine veröffentlichte Spezifikation ist für alles Zeitgesteuerte also der bessere Tausch.

Kann der Connector meine Erwähnungen oder Antworten auf X lesen?

Nein. Erwähnungen zu lesen braucht die eigene API von X, die die AdaptlyPost-Spezifikation nicht umschließt. Ein Muse-Connector auf dieser Spezifikation veröffentlicht, meldet das Ergebnis pro Plattform und kann die /analytics/*-Endpunkte lesen, die Spezifikation definiert aber keinen Endpunkt für eine Timeline mit Erwähnungen oder Antworten.

Funktioniert der Connector mit einem X-Premium-Konto?

Ja. Die Spezifikation setzt kein maxLength für text, nichts im Schema weist also einen Post in Premium-Länge ab, und X wendet das Limit an, das Ihr Konto mitbringt. Schreiben Sie die lange Fassung in platformTexts für TWITTER und eine kurze Fassung für die anderen Netzwerke in denselben Aufruf.

Worin unterscheidet sich das vom Weg über den Grok Bot?

Die Grok-Bot-Vorlage für X-Posts ist ein Share-Link, der eine fertige Konfiguration installiert, das API-Wissen kommt also mit der Vorlage mit. Metas Hilfeseiten zu Connectors, Freigaben und Datenschutz beschreiben für Muse Stand 20. September 2026 weder eine Vorlage noch einen Share-Link-Mechanismus. Muse liest die Spezifikation, schreibt den Client selbst und speichert das Ergebnis dann als wiederverwendbaren Skill, der über Konversationen hinweg bestehen bleibt.

Legt das Token fest, unter welchem X-Konto Muse postet?

Nein. Das X-Handle wird von der Verbindungs-ID bestimmt, die Sie in twitterConnectionIds setzen, nicht vom Token. Rufen Sie GET /social-accounts auf und lassen Sie sich das Handle vor der ersten Veröffentlichung vorlesen. Zugangsdaten-Abfrage und Widerruf stehen im Leitfaden zum Connector.

Wie viele X-Posts kann ein Bulk-Aufruf planen?

POST /social-posts/bulk nimmt 1 bis 100 Posts in einem Aufruf entgegen. Plattformen, timezone und die Arrays mit den Verbindungs-IDs stehen einmal oben in der Anfrage, und jeder Post trägt sein eigenes contentType, text und scheduledAt.

Welches Feld nutzt Muse, um Bluesky in dieselbe Anfrage aufzunehmen?

Bluesky nimmt blueskyConnectionIds, neben twitterConnectionIds für X. Die Spezifikation definiert für keines der beiden Netzwerke einen Config-Block, die Anfrage bekommt also nur ein zweites Array.

Was passiert, wenn meine X-Verbindung vor einem geplanten Post abläuft?

Der Post schlägt zum Veröffentlichungszeitpunkt fehl, nicht beim Planen, und die ursprüngliche Antwort enthält keine Warnung. GET /social-posts/{id}/results zeigt das Ergebnis pro Plattform. Nach dem erneuten Verbinden führt POST /social-posts/{id}/retry nur die Fehlschläge erneut aus.

Wie vermeide ich, jeden Post eines Threads einzeln freizugeben?

Wähle in Metas Freigabe-Abfrage Allow for this task. Sentinel autorisiert jede ausgehende Anfrage der VM, und diese Option deckt den ganzen Lauf ab, statt bei jedem Post nachzufragen. Die anderen Optionen sind Allow once, Allow for this site, Always allow und Deny.

Prüft Meta einen Custom Connector für X?

Nein. Meta gibt an, Custom Connectors und ihren Umgang mit deinen Daten nicht zu prüfen. Lies das X-Handle vor der ersten Veröffentlichung mit GET /social-accounts zurück.

Erstellen Sie ein AdaptlyPost-API-Token und geben Sie Muse die Spezifikation, oder lesen Sie zuerst das Aufbau-Briefing für Agenten. API-Zugriff ist in Creator für $19 im Monat, Pro für $39 und Enterprise für $89 enthalten sowie in der 7-tägigen Testphase.

Quellen: Metas Hilfe-Artikel zu Muse-Connectors, Metas Beitrag zur Sicherheitstechnik, Parallels Bericht zu Custom Integrations (14. September 2026) und die AdaptlyPost-OpenAPI-Spezifikation. Geprüft am 20. September 2026.