Skip to main content
Die REST-API enthält in der Antwort gegebenenfalls eine Liste von Fehlern.
Fehler haben einen zurückgegebenen Statuscode von 400, 401, 402, 403, 404, 429, 500, 502, 503 oder 504. Erfolg hat einen zurückgegebenen Statuscode 200. Details finden Sie hier.
Jeder API-Aufruf kann je nach spezifischer Anfrage und aufgetretenen Problemen im sozialen Netzwerk unterschiedliche Fehler zurückgeben. Die Fehlerantwort enthält Details darüber, was während des API-Aufrufs schiefgelaufen ist. Beispielsweise würde ein Beitrag, der von Twitter und Facebook als Duplikat betrachtet wird, die folgende Antwort zurückgeben.
Bitte beachten Sie:
  • Das Feld errors enthält das Array der Fehler, einen pro sozialem Netzwerk, in dem ein Fehler aufgetreten ist.
  • action bezieht sich auf die Art des zurückgegebenen Fehlers.
  • Das übergeordnete Feld status ist „error”, wenn der API-Aufruf fehlgeschlagen ist. Bei einem /post-Aufruf beispielsweise ist das Feld status „success”, wenn alle Veröffentlichungen in sozialen Netzwerken erfolgreich waren, andernfalls ist das Feld status „error”.
  • Das Feld code enthält den Ayrshare-Referenzfehlercode.
  • Das Feld message enthält die spezifischen Details zum Fehler.

Fehlerbehandlung

Sie sollten alle Fehlerantworten behandeln und die entsprechenden Maßnahmen ergreifen. Ein Fehler ist aufgetreten, wenn:
  • Der Antwort-Rückgabecode nicht 200 ist
  • Der JSON-Antwortstatus error ist
Wenn beispielsweise die Facebook-Verknüpfung von Ihrem Nutzer entfernt wurde – der Nutzer hat sein Passwort geändert oder Ayrshares Zugriff entfernt – würde beim Posten die folgende Antwort mit einem Antwortcode 400 Bad Request ausgegeben.
Eine mögliche Maßnahme wäre, Ihren Nutzer über Ihr Dashboard, per SMS oder E-Mail zu benachrichtigen. Ein weiteres Beispiel ist, wenn das veröffentlichte Instagram-Bild falsche Abmessungen oder ein falsches Seitenverhältnis hat, mit einem Antwortcode 400 Bad Request:
Eine mögliche Maßnahme wäre, die Bilder mit dem korrekten Seitenverhältnis erneut zu senden.

Fehler bei doppelten und ähnlichen Inhalten

Bevor ein Beitrag ein soziales Netzwerk erreicht, vergleicht Ayrshare ihn mit Ihren übrigen Beiträgen und lehnt identische oder nahezu identische Inhalte mit Code 137 ab. Diese Prüfung führt Ayrshare selbst durch, sodass ein Beitrag auch dann abgelehnt werden kann, wenn das Netzwerk ihn zugelassen hätte. Sie gilt nicht für alle Plattformen — siehe die Ausnahmen weiter unten.
Das Zeitfenster. Jeder Beitrag wird gegen ein 48-Stunden-Fenster geprüft, das um sein eigenes scheduleDate zentriert ist — 24 Stunden davor bis 24 Stunden danach. Da das Fenster sowohl vorwärts als auch rückwärts reicht, kann ein Beitrag auch wegen eines später geplanten Beitrags abgelehnt werden, nicht nur wegen eines früheren. Was verglichen wird.
  • Der Abgleich erfolgt pro User Profile und pro Plattform. Derselbe Text an X/Twitter und an LinkedIn gilt nicht als Duplikat, und zwei verschiedene User Profiles kollidieren nicht.
  • X/Twitter ist die Ausnahme, allerdings nur bei exakten Duplikaten: Ein identischer Beitrag wird zusätzlich gegen alle User Profiles desselben Kontos geprüft, da X denselben Inhalt über mehrere Handles hinweg nicht zulässt. Bei nahezu identischen (ähnlichen) Inhalten bleibt die Prüfung auf das einzelne veröffentlichende User Profile beschränkt.
  • Für Pinterest, Reddit und Telegram findet keine Duplikatprüfung statt.
Um häufiger zum selben Thema zu posten, erstellen Sie Varianten mit der Generate API.

Instagram-spezifische Fehlercodes

Die folgenden Fehlercodes liefern spezifische Details zu Instagram-Veröffentlichungsfehlern und ersetzen nach Möglichkeit den generischen Fehler 138. Code 435 – Instagram-Ratenlimit (HTTP 429) Professionelle Instagram-Konten (Business / Creator) unterliegen einem rollierenden 24-Stunden-Limit von 50 Beiträgen über Metas Content Publishing API (private Konten können überhaupt nicht über die API veröffentlichen und erreichen dieses Limit daher nie). Wenn die Obergrenze überschritten wird, gibt Meta einen Ratenlimit-Fehler zurück. Ayrshare gibt auch code: 435 zurück, wenn Metas Publish-Endpunkt direkt HTTP 429 zurückgibt oder wenn der zugrunde liegende Fehler-Subcode (1390008) auf eine Beitrags-/Kommentar-Drosselung hinweist.
Maßnahme: Warten Sie, bis das Ratenlimit-Fenster zurückgesetzt wird, bevor Sie es erneut versuchen. Wenn Meta einen Retry-After-Header liefert, wird der Wert (in Sekunden) im Feld details weitergegeben – warten Sie mindestens so lange, bevor Sie erneut senden. Code 436 – Instagram-Zeitüberschreitung bei Medienverarbeitung (HTTP 400) Instagram hat zu lange gebraucht, um die hochgeladenen Medien zu verarbeiten. Dies kann bei großen Videodateien oder in Zeiten hoher Auslastung auf Metas Servern passieren.
Maßnahme: Wiederholen Sie den Beitrag über den retry post-Endpunkt. Wenn das Problem weiterhin besteht, versuchen Sie, die Größe der Mediendatei zu reduzieren. Code 447 – Instagram Trial Reels: fehlende graduationStrategy (HTTP 400) Wird zurückgegeben, wenn instagramOptions.trialParams bei einer /post-Anfrage angegeben ist, aber graduationStrategy fehlt, null oder ein leerer String ist. Trial Reels erfordern eine explizite Graduation-Strategie – siehe Trial Reels.
Maßnahme: Setzen Sie instagramOptions.trialParams.graduationStrategy entweder auf "MANUAL" oder "SS_PERFORMANCE" und versuchen Sie es erneut, oder entfernen Sie trialParams, wenn Sie kein Trial Reel veröffentlichen wollten. Code 448 – Instagram Trial Reels: ungültige graduationStrategy (HTTP 400) Wird zurückgegeben, wenn graduationStrategy vorhanden ist, aber nicht genau "MANUAL" oder "SS_PERFORMANCE" entspricht. Die Prüfung ist case-sensitive – Werte wie "manual" oder "ss_performance" werden abgelehnt. Das Feld details gibt den abgelehnten Eingabewert wieder (auf 64 Zeichen gekürzt), um das Debugging zu erleichtern.
Maßnahme: Senden Sie graduationStrategy genau als "MANUAL" oder "SS_PERFORMANCE" (Großbuchstaben, Typ String). Code 449 – Instagram Trial Reels: inkompatible Medien (HTTP 400) Wird zurückgegeben, wenn die Medien oder die Struktur des Beitrags nicht für ein Trial Reel geeignet sind. Trial Reels müssen ein einzelnes .mp4- oder .mov-Video sein – Karussells (mehr als eine URL), Stories (instagramOptions.stories: true) und Nicht-Video-Erweiterungen werden alle abgelehnt. Das Feld details unterscheidet, welcher Unterfall ausgelöst wurde.
Maßnahme: Senden Sie eine einzelne .mp4- oder .mov-Video-URL ohne stories: true-Flag. Entfernen Sie zusätzliche mediaUrls-Einträge oder entfernen Sie trialParams, wenn Sie einen regulären Karussell-/Story-Beitrag beabsichtigt haben. Code 258 – Instagram-Kontostatus-Fehler (HTTP 400) Ein allgemeiner Instagram-Kontostatus-Fehler mit der Basismeldung „Error with Instagram.” Dieser tritt auf, wenn Meta die Anfrage aufgrund des Zustands des verknüpften Instagram-Kontos ablehnt und nicht wegen des Inhalts des Beitrags.
Wenn der zugrunde liegende Meta-error_subcode 2207085 („Generic Internal Error”) ist, handelt es sich um einen vorübergehenden Fehler auf Meta-Seite. Ayrshare wiederholt die Veröffentlichung automatisch über bis zu etwa 50 Sekunden, bevor der Fehler zurückgegeben wird, und die Antwort setzt retryAvailable: true. Sie setzt nicht relink: true — ein erneutes Verknüpfen behebt diesen Zustand nicht. Wenn Meta eine fbtrace_id liefert, wird sie in details zurückgegeben:
Maßnahme: Wiederholen Sie im Unterfall 2207085 den Beitrag in einigen Minuten — dies ist ein Zustand auf Meta-Seite, der sich in der Regel von selbst löst, und ein erneutes Verknüpfen hilft nicht. Nur wenn der Fehler länger als 24-48 Stunden besteht, fordern Sie den Nutzer auf, sein Instagram-Konto in Social Accounts zu trennen und erneut zu verknüpfen und dabei alle angeforderten Berechtigungen zu gewähren, oder wenden Sie sich mit der fbtrace_id aus details an den Meta-Support. Bei anderen Kontostatus-Fehlern prüfen Sie, ob das Instagram-Konto bei Meta einen guten Stand hat, und versuchen Sie es erneut.

Wiederholung verfügbar

Manchmal treten in sozialen Netzwerken nicht behebbare Fehler auf, z. B. Serverprobleme, und der Aufruf schlägt letztendlich auch nach zahlreichen Wiederholungen fehl. In diesen Fällen ermittelt unser System, ob der Fehler wiederholbar ist, und wenn ja, ist das Feld retryAvailable gleich true.
Sie können den Aufruf dann mit demselben Payload erneut ausführen. Wenn es sich um einen Beitrag handelt, können Sie den retry post-Endpunkt verwenden.

Instagram-Reels-Audio-Fehler

Diese Codes betreffen das Anhängen von Musik an einen Instagram Reel mit instagramOptions.audioConfiguration sowie die Endpunkte Audio-Suche und Audio-Lookup.
Code 514 lässt sich nicht durch das Erteilen einer Berechtigung oder ein Plan-Upgrade beheben. Metas Audio API „ist nur über die Instagram API mit Facebook Login verfügbar. Sie wird über die Instagram API mit Instagram Login nicht unterstützt.” Ein mit Instagram Login verknüpftes Konto gibt bei jedem Audio-Aufruf 514 zurück, bis es über Facebook Login mit einer verbundenen Facebook Page erneut verknüpft wird.Siehe den Leitfaden zu den Voraussetzungen für das Anhängen von Musik für die vollständige Einrichtung, einschließlich der Stelle, an der sich die Facebook-Page-Verbindung inzwischen in den Facebook-Einstellungen befindet.
Code 518 kommt in postIds[].warnings[] an, nicht in errors[]. Instagram erlaubt einen Track pro Reel; werden also sowohl audioConfiguration als auch audioName gesendet, gewinnt audioConfiguration und audioName wird verworfen. Die Antwort ist weiterhin status: "success" mit HTTP 200 – behandeln Sie 518 als informativ und lassen Sie nichts daran scheitern. Die Warnung ist im postIds-Eintrag der jeweiligen Plattform verschachtelt statt auf oberster Ebene und trägt feature: "audioName".
Die Lautstärke-Validierung meldet das generische 101, keinen eigenen Code. audioVolume und videoVolume müssen Ganzzahlen von 0 bis 100 sein. Eine Dezimalzahl, ein numerischer String wie "80", ein Wert außerhalb des Bereichs oder ein explizites null gibt code: 101 zurück – mit der benannten Grenze in details –, bevor Instagram aufgerufen wird. Lassen Sie das Feld weg, statt null zu senden.

Automation-Private-Reply-Fehler (Kommentar-DM)

Diese Codes erscheinen bei kommentar-getriggerten Automatisierungen (comment_keyword), wenn die Private Reply, die die DM trägt, nicht gesendet werden kann. Sie erscheinen als Activity-Zeile mit status: "failed" und dem Grund in actionResults[].errorDetails. Keiner davon wird automatisch wiederholt – die Instagram Send API hat keinen Idempotency-Key, sodass ein automatischer Retry das Risiko birgt, die DM doppelt zuzustellen. Die Handhabung unterscheidet sich je nach Code (siehe Maßnahme unten): Die meisten sind für diesen bestimmten Kommentar dauerhaft, 492 erfordert eine erneute Kontoverknüpfung, und 493 klärt sich von selbst, wenn das Stundenlimit zurückgesetzt wird.
Code 491 deckt mehrere Ursachen ab, die Instagram nicht unterscheidet, und 490 ist die enge Ausnahme. Instagram gibt einen gemeinsamen Fehler zurück für einen Kommentar, der mehr als 7 Tage alt ist, einen Kommentar, der bereits eine Antwort erhalten hat (pro Kommentar ist immer nur eine Private Reply erlaubt), einen gelöschten Kommentar und einen Kommentator, der Message Requests blockiert. All diese Fälle melden 491.490 wird nur im engeren Fall gemeldet, in dem Instagram die Kommentar-ID direkt als ungültig identifiziert, statt den gemeinsamen Sammel-Bucket zurückzugeben – ein gelöschter Kommentar kann also entweder als 490 oder als 491 erscheinen, je nachdem, was Instagram zurückgibt.Da die API diese nicht trennt, lesen Sie immer errorDetails: Dort steht Instagrams eigener Wortlaut, der die Ursache in der Regel klar benennt.
Code 489 ist reserviert und wird derzeit nicht zurückgegeben. Er ist für den Fall „dieser Kommentar hat bereits eine Antwort” vorgesehen, den Instagram derzeit nicht als eigenes Signal freilegt – dieser Fall meldet heute 491. Er ist hier nur aufgeführt, damit die Nummer nicht wiederverwendet wird.
Eine tatsächlich abgelaufene oder ungültige Verbindung liegt nicht in diesem Bereich. Wenn die gespeicherten Instagram-Anmeldedaten abgelaufen sind, hat die Activity-Zeile status: "auth_error" statt failed, und die richtige Lösung ist, das Konto neu zu verknüpfen. Mit Ausnahme von 492 — einer fehlenden Berechtigung, die durch erneutes Verknüpfen des Kontos erteilt wird — sind die obigen Codes Bedingungen auf Kommentarebene und bedeuten niemals „neu verknüpfen”.
Diese Codes erscheinen in zwei unterschiedlichen Formen, je nachdem, wo Sie sie lesen, und das Feld, das den Instagram-Grund trägt, heißt in jeder Form anders. 1. In der Activity-Zeile der Automatisierung – was GET /automations/:id/activity zurückgibt. Der Instagram-Grund steht in actionResults[].errorDetails:
2. Als direktes API-Fehler-Envelope – die Standard-Fehlerform, bei der derselbe Grund in details steht:
Bei einer kommentar-getriggerten Automatisierung werden Sie fast immer Form 1 lesen. errorDetails trägt dort denselben String, den das Envelope in details legt. Maßnahme:
  • 490, 491, 495 – Bedingungen auf Kommentarebene. Sie können für diesen bestimmten Kommentar nicht behoben werden, und kein Retry hilft; die Automatisierung funktioniert beim nächsten frischen Kommentar normal. Lesen Sie errorDetails für Instagrams angegebenen Grund.
  • 492 – Verknüpfen Sie das Instagram-Konto neu und gewähren Sie alle angeforderten Berechtigungen. Dies ist eine Behebung auf Kontoebene und würde ansonsten jeden Kommentar betreffen.
  • 493 – Keine Maßnahme nötig außer Warten; das Stundenlimit setzt sich von selbst zurück. Wird nicht automatisch wiederholt, daher wird die DM für diesen Kommentar nicht gesendet.
  • 494 – Interne Fehlkonfiguration, keine kundenseitige Bedingung. Wenden Sie sich an den Support, wenn dies wiederholt auftritt.
Ein sent-Status garantiert keine Zustellung. Unabhängig von den obigen Fehlern kann eine Private Reply, die Instagram akzeptiert (status: "sent"), dennoch stillschweigend verworfen werden, wenn die Instagram-Einstellung Message requests des Empfängers Fremde blockiert – dies erzeugt überhaupt keinen Fehlercode. Siehe Automation-DM gesendet, aber nicht zugestellt.

Thread- und Medienoptions-Fehler

Diese Codes werden zurückgegeben, wenn eine Option nicht auf den Beitrag angewendet werden kann – am häufigsten bei einem X-Thread oder Threads-Thread, wo die von Ihnen gesendeten Optionen für den gesamten Thread gelten.
  • 182 – Das Video erfüllt die Anforderung an die Dauer nicht. Das Video ist kürzer als das Minimum des Netzwerks oder länger als sein Maximum. Die Antwort nennt die tatsächliche Dauer des Videos zusammen mit dem angewendeten Minimum und Maximum – vergleichen Sie die drei Werte, um festzustellen, welche Grenze Sie verletzt haben. Auf X reicht der Standardbereich von 0,5 bis 140 Sekunden (2 Minuten 20 Sekunden); um ein längeres Video zu posten, setzen Sie longVideo: true, was das Maximum für ein von X für Long Video zugelassenes Konto auf 4 Stunden anhebt. Andere Netzwerke haben eigene Limits – siehe die Medienrichtlinien für das Netzwerk, auf dem Sie posten.
  • 101 – Fehlende oder falsche Parameter. Auf Threads wird dieser Code zurückgegeben, wenn allowCountries von einem Konto gesendet wird, das Meta nicht für Geo-Beschränkungen berechtigt hat. Kein Teil des Beitrags oder Threads wird veröffentlicht. Prüfen Sie isEligibleForGeoRestrictions über /user, bevor Sie die Option senden.
  • 111 – X hat den Beitrag abgelehnt. Dies ist der allgemeine Code für einen X-Fehler ohne spezifischeren Code – lesen Sie daher die details in der Antwort – sie enthalten die eigene Meldung von X und verraten Ihnen die Ursache. Eine häufige Ursache ist eine Option, zu deren Nutzung das Konto nicht berechtigt ist, etwa subscribersOnly ohne X Subscriptions oder longPost auf einem einzelnen Beitrag ohne X Premium; entfernen Sie in diesem Fall die Option oder prüfen Sie die Berechtigungen des Kontos. Verbindungsfehler und andere Fehler auf X-Seite erscheinen ebenfalls als 111 – bei diesen lohnt sich ein Retry, statt Ihre Anfrage zu ändern.Beachten Sie: longPost ist auf einem Thread keine Ursache für 111 – dort wird es mit einer Warnung ignoriert, und der Thread wird veröffentlicht. Siehe Long Post.
  • 275 – Der Beitrag ist zu lang, um als Thread veröffentlicht zu werden. Das Aufteilen des Textes hat mehr als das Maximum von 30 Beiträgen ergeben. Kürzen Sie den Text oder verteilen Sie ihn auf separate Threads. Eigene Thread-Umbrüche mit \n\n helfen hier nicht – jeder Umbruch erzeugt einen weiteren Beitrag und kann die Anzahl also noch weiter über das Limit treiben.
Eine Option, die Ihr Konto nicht nutzen kann, lässt den gesamten Beitrag fehlschlagen, statt ignoriert zu werden. Bei einem Thread bedeutet das, dass kein Teil des Threads veröffentlicht wird – die bereits veröffentlichten Teile werden für Sie gelöscht. Die Löschung erfolgt nach bestem Bemühen: Lehnt das Netzwerk eine Löschung ab, kann dieser Teil veröffentlicht bleiben – prüfen Sie also den Thread und entfernen Sie, was übrig geblieben ist. Zuvor wurden einige dieser Optionen auf Threads stillschweigend verworfen und der Thread ohne sie veröffentlicht.
Die Codes 501 bis 513 gehören zur Social-Verknüpfung: das Erstellen eines Links mit Eine Link Session erstellen und das Öffnen eines Links. Sie tragen "action": "link session". Andere 500er-Codes auf dieser Seite haben damit nichts zu tun – 514 bis 518 sind Instagram-Reels-Audio. Matchen Sie auf den numerischen code, nicht auf den Meldungstext, der variieren oder übersetzt sein kann. Welche davon Ihre Seite hören kann. Mit gesetztem origin sendet ein Verknüpfungs-Popup Link-Completion-Events an Ihre Seite, und 513 kann auf diesem Weg als connect:error ankommen. 501, 502 und 503 können das nicht: Ein toter Link wird verweigert, bevor die Seite erfährt, wohin Events zu senden sind – Ihr Nutzer sieht den Grund also auf dem Bildschirm, und Ihre Seite hört connect:cancelled, wenn er das Fenster schließt. Um diese drei zu unterscheiden, pollen Sie Eine Link Session abrufen. 504 bis 510 sind Ablehnungen des POST selbst und kommen nie als Events an, und 511 und 512 entstehen, während das soziale Netzwerk zurückruft – sie tauchen also dort auf und nicht auf Ihrer Seite.

X/Twitter BYO-Key-Fehler

Die folgenden Fehlercodes sind spezifisch für X/Twitter BYO-Key-Operationen (Bring Your Own): Code 272 – Verifizierung der BYO-Twitter-Identität fehlgeschlagen (HTTP 400) Ayrshare konnte Ihre X/Twitter-Identität mit Ihren BYO-Consumer-Keys und den zum Zeitpunkt der Verknüpfung gespeicherten OAuth-Tokens nicht bestätigen. Die Antwortform variiert je nach dem Aufruf, der den Fehler ausgelöst hat; beide Formen ordnen sich denselben drei Unterfällen unten zu. Prüfen Sie, welcher Fall zutrifft, indem Sie sich bei x.com mit dem Konto anmelden, dem die BYO Developer App gehört. Der Post-Pfad gibt eine minimale Antwort aus:
Der Analytics-Pfad gibt eine ausführlichere, selbstdokumentierende Meldung aus und kann ein Feld details mit der Roh-Fehlermeldung von X enthalten:
Wenn vorhanden, spiegelt details den Hinweis von X wider und ist das zuverlässigste Einzelsignal dafür, welcher Unterfall unten zutrifft. Konto gesperrt. Beim Login bei x.com wird ein Sperrhinweis angezeigt. Maßnahme: Wenden Sie sich an den X-Support. Ein erneutes Verknüpfen stellt den Zugriff erst wieder her, wenn X das Konto wiederherstellt. Konto gesperrt (locked). Beim Login bei x.com wird eine Entsperr-Challenge (CAPTCHA, Telefonverifizierung usw.) angezeigt. Maßnahme: Schließen Sie die Entsperr-Challenge auf x.com ab und wiederholen Sie dann die Anfrage. Ein erneutes Verknüpfen ist nicht erforderlich. Identitäts- oder Schlüssel-Mismatch. Ihr X-Konto ist auf x.com in gutem Zustand, aber Ihre BYO-Consumer-Keys gehören zu einer anderen X Developer App als die zum Zeitpunkt der Verknüpfung gespeicherten OAuth-Tokens. Maßnahme: Verknüpfen Sie X unter Social Accounts erneut und autorisieren Sie mit demselben X-Konto, dem die BYO Developer App gehört. Code 364 – X-Ratenlimit (HTTP 429) X hat eine mit Ihren BYO-Keys gestellte Anfrage gedrosselt. Dies ist der gemeinsame Ratenlimit-Code von Ayrshare, und er deckt jetzt auch den Lesepfad für X-Kommentare ab: Get Comments gibt ihn zurück, wenn X den Read per Ratenlimit einschränkt, wo zuvor stattdessen eine leere Kommentarliste zurückkam.
Maßnahme: Warten Sie, bis das Ratenlimit-Fenster von X zurückgesetzt wird, und versuchen Sie es dann erneut. X wendet seine Limits pro X Developer App an, sodass Anfragen aller User Profiles, die dieselben BYO-Keys verwenden, auf dasselbe Limit angerechnet werden. Code 416 – X-Credits erschöpft (HTTP 402) Auf Ihrem X-Developer-Konto sind keine API-Credits geladen. Alle X-API-Aufrufe erfordern Credits, daher kann dieser Code auf jedem X-Pfad zurückgegeben werden: beim Posten, bei Analytics und bei Reads wie Get Comments. Auf dem Kommentarpfad ersetzt er die leere Kommentarliste, die zuvor zurückkam, sodass erschöpfte Credits nicht mehr als Beitrag ohne Kommentare gemeldet werden. Medien-Uploads zählen als API-Aufrufe. Das Senden eines Bildes oder Videos mit einem X-Beitrag gibt code: 416 zurück, wenn das Konto keine Credits mehr hat. 416 ist also nicht auf das Veröffentlichen von Text oder das Abrufen von Analysedaten beschränkt. Der Upload schlägt fehl, bevor der Beitrag veröffentlicht wird, und es erfolgt kein erneuter Versuch – kein erneuter Versuch kann erfolgreich sein, solange keine Credits auf dem Konto sind.
Maßnahme: Gehen Sie zu console.x.com → Billing → Credits und kaufen Sie Credits. Bereits $5 reichen für hunderte API-Aufrufe. Code 417 – OAuth 1.0a-App-Berechtigungen (HTTP 403) Ihr X-Access-Token verfügt nicht über die richtigen Berechtigungen für die angeforderte Operation.
Möglicherweise sehen Sie auch den Antwort-Header x-access-level: read, der bestätigt, dass Ihr Access-Token mit Nur-Lese-Berechtigungen generiert wurde. Maßnahme: Aktualisieren Sie in der X Developer Console die App-Berechtigungen auf Read and write and Direct message und regenerieren Sie dann Ihren Access-Token unter Keys and tokens. Der neue Token erbt die aktualisierten Berechtigungen. Details finden Sie im X BYO Key Setup Guide. Code 419 – Fehlende BYO-Anmeldedaten (HTTP 400) X/Twitter-Operationen erfordern BYO-API-Anmeldedaten in den Anfrage-Headern. Ayrshare gibt Code 419 zurück, wenn beide Header fehlen, und auch wenn nur einer des Paares vorhanden ist. Der message-String variiert je nachdem, welche(r) Header fehlt/fehlen. Wenn sowohl X-Twitter-OAuth1-Api-Key als auch X-Twitter-OAuth1-Api-Secret fehlen:
Wenn nur einer des Paares vorhanden ist (zum Beispiel der Key ohne das Secret):
Maßnahme: Senden Sie sowohl X-Twitter-OAuth1-Api-Key als auch X-Twitter-OAuth1-Api-Secret bei jeder X-Anfrage. Wenn Sie einen ohne den anderen bereitstellen, wird die Anfrage mit demselben Code abgelehnt. Die vollständige Header-Liste finden Sie unter X BYO Keys Header Reference. Code 423 – Legacy-X/Twitter-OAuth nicht mehr unterstützt (HTTP 403) Wird zurückgegeben, wenn eine X/Twitter-Anfrage den Legacy-Pfad (Nicht-BYO) OAuth verwendet, der nicht mehr unterstützt wird. Der Zugriff auf die X-API erfordert jetzt Ihre eigenen X-Developer-App-Anmeldedaten, die über Anfrage-Header bereitgestellt werden.
Maßnahme: Konfigurieren Sie eine X Developer App und senden Sie die Header X-Twitter-OAuth1-Api-Key und X-Twitter-OAuth1-Api-Secret bei jeder X-Anfrage. Die vollständigen Einrichtungsschritte finden Sie im X BYO Key Setup Guide.

Fehler bei Caption-Enhancement

Code 441 – Caption-Enhancement fehlgeschlagen (HTTP 502) Wird zurückgegeben, wenn ein Caption-Enhancement (z. B. shortenLinks) für eine oder mehrere Plattformen beim Vorbereiten eines Beitrags fehlschlägt. Jede betroffene Plattform erscheint im errors-Array mit source: "handlePostAdditions" und code: 441. Wenn nur einige Plattformen fehlschlagen, veröffentlichen die anderen Plattformen dennoch erfolgreich und ihre Ergebnisse erscheinen in postIds. In diesem Fall ist der übergeordnete status "error", aber postIds ist nicht leer – Clients sollten status und errors[] als komplementär und nicht als sich gegenseitig ausschließend behandeln.
Wenn alle Plattformen beim Enhancement fehlschlagen, ist die Antwort ein übergeordneter code: 441 mit HTTP 502, und es wird kein Beitrag erstellt:
Maßnahme: Caption-Enhancement-Fehler sind in der Regel transient (der zugrunde liegende Shortener- oder Enhancement-Dienst hat einen Fehler zurückgegeben).
  • Wenn postIds nicht leer ist (einige Plattformen haben erfolgreich veröffentlicht), senden Sie den vollständigen Plattform-Satz nicht erneut – dies würde den Beitrag auf den erfolgreichen Plattformen duplizieren. Prüfen Sie stattdessen errors[], um die fehlgeschlagenen Plattformen zu identifizieren, und wiederholen Sie die Anfrage nur mit diesen Plattformen, oder verlassen Sie sich auf Ihren eigenen idempotenten Retry-Flow.
  • Wenn postIds leer oder nicht vorhanden ist (kompletter Fehler zum Zeitpunkt des Zeitplans/Posts), können Sie die vollständige Anfrage gefahrlos wiederholen.
  • Wenn der Fehler weiter besteht, senden Sie den Beitrag ohne das Enhancement-Flag (z. B. lassen Sie shortenLinks weg) oder wenden Sie sich an den Support.

Fehler beim Medienabruf / Crawler-Zugriff

Code 499 – Ayrshare Media Probe vorübergehend nicht verfügbar (HTTP 503) Wird zurückgegeben, wenn Ayrshare die vor der Veröffentlichung durchgeführte Medienprüfung nicht abschließen kann, weil der interne Media-Probe-Dienst nicht erreichbar war oder eine ungültige Antwort geliefert hat. Dies ist ein Ayrshare-Dienstfehler und kein Beleg dafür, dass Ihre Medien-URL, Ihr CDN, Ihre User-Agent-Regeln oder Ihre robots.txt-Konfiguration fehlerhaft sind. Der Fehler enthält retryAvailable: true; wiederholen Sie die fehlgeschlagene Plattform in Kürze. Wenn eine Multi-Plattform-Anfrage teilweise erfolgreich war, wiederholen Sie nur die in errors[] aufgeführten Plattformen, um doppelte Beiträge zu vermeiden.
Code 164 – Ayrshare konnte nicht auf die Medien zugreifen (HTTP 400) Code 164 ist ein älterer Medien-Zugriffs-/Eingabe-Envelope, der in mehreren Pfaden verwendet wird, darunter fehlerhafte mediaUrls, nicht lesbare Medien sowie einige Netzwerk-Upload-/Abruf-Fehler. Prüfen Sie zunächst alle zurückgegebenen details. Bei einem Zugriffsfehler stellen Sie sicher, dass die URL öffentlich erreichbar ist, lange genug für die Veröffentlichung gültig bleibt und Remote-Anfragen nicht blockiert. /media/urlExists führt nur eine HEAD-Erreichbarkeitsprüfung durch; ein erfolgreiches Ergebnis dort garantiert nicht, dass die tiefergehende Medienprüfung vor der Veröffentlichung oder der Crawler eines sozialen Netzwerks die Datei herunterladen und verarbeiten kann. Wenn der konkrete Fehler darin besteht, dass der Media-Probe-Dienst von Ayrshare selbst nicht verfügbar ist, erhalten Sie stattdessen den wiederholbaren Code 499. Code 440 – Soziales Netzwerk konnte Medien nicht herunterladen (HTTP 400) Wird zurückgegeben, wenn der Publishing-Crawler der Plattform die von Ihnen angegebene mediaUrl nicht herunterladen kann – am häufigsten, weil robots.txt oder eine WAF-/Bot-Fight-Regel den Crawler blockiert (z. B. Metas facebookexternalhit). Der details-String stammt von der Upstream-Plattform und ist häufig der Fehlertext 2207052 von Meta/Instagram.
Code 138 – Instagram-Medienabruf blockiert (HTTP 400) Fallback-Code für Instagram-Medienabruf-Fehler, wenn die Upstream-Antwort weniger spezifisch ist als die, die Code 440 auslöst. Der details-String enthält typischerweise "Restricted by robots.txt" oder "HTTP error code 403". Code 138 wird auch für Seitenverhältnis-/Format-Probleme und andere generische Instagram-Fehler verwendet, sodass die Medienabruf-Variante am details-String erkennbar ist.
Code 379 – Threads-Veröffentlichungsfehler Wird zurückgegeben, wenn die Threads-Veröffentlichung fehlschlägt. Am häufigsten verursacht durch dasselbe Medienabruf-Problem wie bei Codes 440 / 138, wenn auf beiden Plattformen mit derselben mediaUrl veröffentlicht wird. Die Threads-API gibt keine Detail-Strings zurück, sodass die Diagnose in der Regel erfordert, dass beim selben Veröffentlichungsvorgang gleichzeitig ein Instagram-440 oder -138 auftritt.
Maßnahme: Siehe Meta Media Crawler Blocked für die vollständige Fehlerbehebung, einschließlich robots.txt-Snippets und eines Prüfbefehls.

Threads-Medien nicht bereit

Code 522 – Threads-Medien nicht zur Veröffentlichung bereit (HTTP 400) Threads hatte die Vorbereitung des Beitrags noch nicht abgeschlossen, als Ayrshare versuchte, ihn zu veröffentlichen. Threads kann einen Beitrag einige Sekunden bevor es die Veröffentlichung annimmt bereits als bereit melden. Ayrshare wartet und versucht es bei einem Threads-Beitrag insgesamt bis zu 30 Sekunden lang erneut, über alle Teile eines mehrteiligen Threads hinweg, bevor dieser Fehler zurückgegeben wird. Daher werden die meisten dieser Beiträge jetzt ohne Fehler veröffentlicht. Das Problem ist in der Regel vorübergehend und liegt bei Threads; Ihr Inhalt ist nicht die Ursache. Threads-Kommentare, -Antworten und erste Kommentare erhalten dieselbe Wartezeit (ein erster Kommentar erhält nach der Veröffentlichung des Beitrags eigene 30 Sekunden), geben aber nicht Code 522 zurück. Bei einem mehrteiligen Thread befindet sich das code: 522-Objekt nicht direkt in errors: Es ist der letzte Eintrag im posts-Array des Threads-Fehlers, und der oben genannte HTTP-Status 400 gilt nur für einen einzelnen Threads-Beitrag. noAutoRetry: true verhindert lediglich, dass der Ayrshare MCP-Server den Beitrag selbstständig wiederholt; Sie können ihn trotzdem wiederholen.
Maßnahme: Sie müssen den Beitrag nicht ändern. Prüfen Sie zuerst postIds. Wenn nichts veröffentlicht wurde, wiederholen Sie den Beitrag über den retry post-Endpunkt. Wenn eine andere Plattform desselben Beitrags bereits veröffentlicht hat, senden Sie stattdessen einen neuen Beitrag nur an Threads: retry post sendet das ursprüngliche Payload erneut an jede Plattform, wodurch die erfolgreichen Plattformen ein zweites Mal veröffentlichen würden. Mehrteilige Threads: Ein leeres postIds beweist nicht, dass kein Teil des Threads live ist. Ayrshare entfernt die bereits veröffentlichten Teile, wenn ein späterer Teil fehlschlägt. Schlägt eine Entfernung jedoch fehl, bleibt dieser Teil auf Threads bestehen. Prüfen Sie vor dem Wiederholen eines mehrteiligen Threads das Threads-Konto und löschen Sie alle noch vorhandenen Teile, da sie sonst durch die Wiederholung erneut veröffentlicht werden.

Facebook-Analytics-Ratenlimit

Code 444 – Facebook Page Analytics-Ratenlimit (HTTP 429) Wird zurückgegeben, wenn eine Facebook Page Metas Ratenlimit pro Page am Analytics-Endpunkt überschritten hat. Der zugrunde liegende Meta-Fehler ist 80001 („There have been too many calls to this Page account.”). Die Page bleibt verknüpft und die Veröffentlichung funktioniert weiterhin – nur der Analytics-Fan-out für diese Page ist gedrosselt. Wenn die Drosselung für einen einzelnen Beitrag in einer /history/facebook- oder analytics-Antwort erkannt wird, führt jeder betroffene Beitrag code: 444 unter facebook.code mit errCode: 80001:
Maßnahme: Warten Sie einige Minuten und versuchen Sie es erneut. Metas Ratenlimit-Fenster pro Page löst sich in der Regel innerhalb einer Stunde ohne Zutun der Page auf. Fordern Sie den Nutzer nicht auf, das Konto neu zu verknüpfen – dies ist eine transiente Drosselung auf Metas Seite und kein Autorisierungsfehler.
Wenn Sie diesen Zustand zuvor als code: 161 („Facebook authorization error … unlink and re-link”) behandelt haben, aktualisieren Sie Ihre Integration, um code: 444 zu erkennen und stattdessen mit Backoff zu wiederholen, anstatt einen Relink-Flow zu initiieren. Die Klassifizierung 161 wurde im April 2026 korrigiert.

Meta-Identitätsverifizierung

Code 326 – Meta-Identitätsverifizierung erforderlich (HTTP 403) Wird zurückgegeben, wenn Meta für das verknüpfte Konto eine zusätzliche Identitätsverifizierung verlangt, bevor die Anfrage akzeptiert wird. Dies gilt plattformübergreifend bei Meta – Facebook, Instagram, Facebook Groups, Threads und Messenger. Ein erneutes Verknüpfen des Kontos löst das Problem nicht; die Verifizierung muss auf Metas Seite abgeschlossen werden.
Maßnahme: Lassen Sie den Kontoinhaber Metas Identitätsverifizierung unter Meta Business Support abschließen und wiederholen Sie dann die Anfrage. Fordern Sie den Nutzer nicht auf, das Konto neu zu verknüpfen – ein Relink löscht diese Anforderung nicht.

Facebook-Sperre wegen Community-Standards

Code 249 – Facebook-Sperre wegen Community-Standards (HTTP 400) Wird zurückgegeben, wenn Facebook einen Beitrag aufgrund seiner Community-Standards blockiert. Die Sperre kann auf dem Facebook-Konto bzw. der Page oder auf dem Beitrag selbst liegen. Facebook verwendet für beide Fälle denselben zugrunde liegenden Fehler und gibt nicht an, welcher zutrifft. In der Praxis wird die Sperre meist auf das Konto oder die Page verhängt, sodass ein Umschreiben oder erneutes Senden des Inhalts häufig nicht hilft. Wie die Facebook-Konto-Einschränkung (Code 476) ist dies eine Durchsetzungsmaßnahme auf Metas Seite. Sie ist nicht wiederholbar und trägt kein retryAvailable-Flag. Bei einem ersten Verstoß bleibt das Konto mit Ayrshare verknüpft und ein Relink ist nicht erforderlich; ein Relink hebt die Sperre ohnehin nicht auf. Bei einem wiederholten Verstoß sieht es anders aus, siehe unten. Facebook gibt den spezifischen Grund nicht über die API zurück, sodass der Kunde die Seite Account Status (Kontostatus) von Facebook direkt prüfen muss, um den Grund zu sehen und Einspruch zu erheben. Wenn Facebook einen eigenen Wortlaut liefert, gibt Ayrshare diesen im Feld details wieder. Ayrshare sendet dem Kontoinhaber außerdem eine Benachrichtigungs-E-Mail, wenn die Sperre erkannt wird. Ein wiederholter Verstoß gegen die Community-Standards im selben User Profile trennt die Verknüpfung des Facebook-Kontos mit Ayrshare und sperrt das User Profile.
Prüfen Sie den numerischen code-Wert 249, nicht den message-Text. Der Wortlaut von message kann im Laufe der Zeit angepasst werden, während der Code stabil bleibt. Maßnahme: Melden Sie sich bei Facebook an, klicken Sie auf Ihr Profilbild (oben rechts), öffnen Sie den Bereich Hilfe und wählen Sie Account Status (Kontostatus). Der Support-Assistent von Facebook zeigt dort den spezifischen Grund an (den die API nicht zurückgibt) und ermöglicht Ihnen, Einspruch einzulegen. Fordern Sie den Nutzer nicht auf, das Konto neu zu verknüpfen – ein Relink hebt eine Sperre auf Konto- oder Page-Ebene nicht auf. Die vollständige Anleitung zur Fehlerbehebung finden Sie unter Facebook- oder Instagram-Konto eingeschränkt?.

Facebook-Konto-Einschränkung

Code 476 – Facebook-Konto-Einschränkung (HTTP 400) Wird zurückgegeben, wenn ein Beitrag auf Facebook fehlschlägt, weil Meta eine Einschränkung für das Konto verhängt hat (Meta-Fehler-Subcodes 2424009 und 1404078 oder Metas Restriktions-Wortlaut, wenn der Fehler keinen Subcode trägt). Dies ist eine Einschränkung auf Kontoebene, kein vorübergehender Veröffentlichungsfehler – sie ist nicht wiederholbar und trägt kein retryAvailable-Flag. Ein erneutes Senden desselben Beitrags wird erst erfolgreich sein, wenn die Einschränkung mit Meta geklärt ist. Das Konto bleibt mit Ayrshare verknüpft; ein Relink ist nicht erforderlich. Meta gibt den spezifischen Grund für die Einschränkung nicht über die API zurück, sodass der Kunde Metas Kontostatus-Seite direkt prüfen muss, um den Grund zu sehen und Einspruch zu erheben. Wenn Meta einen eigenen Wortlaut liefert, gibt Ayrshare diesen im Feld details wieder. Ayrshare sendet dem Kontoinhaber außerdem eine Benachrichtigungs-E-Mail, wenn die Einschränkung erkannt wird.
Maßnahme: Melden Sie sich bei Facebook an, klicken Sie auf Ihr Profilbild (oben rechts), öffnen Sie den Bereich Hilfe und wählen Sie Kontostatus. Metas Support-Assistent dort zeigt den spezifischen Grund für die Einschränkung an und ermöglicht Ihnen Einspruch. Da die Einschränkung von Meta auf Kontoebene durchgesetzt wird, ist dieser Code nicht wiederholbar – bauen Sie keine automatische Retry-Logik darum herum; klären Sie die Einschränkung zuerst mit Meta.

Fehler bei der Bildformatkonvertierung

Ayrshare konvertiert WebP-, HEIC-, HEIF- und AVIF-Bilder automatisch in JPEG, bevor auf Plattformen veröffentlicht wird, die sie nicht akzeptieren (Instagram, LinkedIn, TikTok, Google My Business, Threads und Snapchat für WebP; alle Plattformen für HEIC, HEIF und AVIF). Die Konvertierung läuft transparent zum Zeitpunkt des Sendens. Die drei folgenden Fehler treten nur auf, wenn die Konvertierungspipeline selbst nicht abgeschlossen werden kann; wenn das Quellbild bereits in einem unterstützten Format vorliegt, wird keine Konvertierung versucht und diese Codes erscheinen nicht. Code 450 – Bildformatkonvertierung fehlgeschlagen (HTTP 400) Das Bild wurde heruntergeladen, konnte aber nicht als JPEG neu kodiert werden. Häufigste Ursachen sind eine beschädigte Quelldatei, ein unerwartetes internes Format im Container oder ein Bild, das die Konvertierungs-Größenobergrenze überschreitet.
Maßnahme: Öffnen Sie die Quell-mediaUrl direkt in einem Browser, um zu bestätigen, dass sie dargestellt wird. Wenn ja, exportieren Sie das Bild in ein sauberes JPEG oder PNG und wiederholen Sie den Beitrag. Code 451 – Bilddownload für Konvertierung fehlgeschlagen (HTTP 400) Die Konvertierungspipeline konnte das Quellbild nicht abrufen. Typische Ursachen sind eine 4xx-/5xx-Antwort vom Ursprung, ein Netzwerk-Timeout, eine Weiterleitungskette, die die Hop-Grenze überschreitet, oder eine URL, die zu einer nicht-öffentlichen Adresse aufgelöst wird (durch die SSRF-Guard blockiert). Das Feld details enthält, sofern vorhanden, den zugrunde liegenden Ursachen-String.
Maßnahme: Bestätigen Sie, dass die mediaUrl öffentlich erreichbar ist (keine Authentifizierung, keine robots.txt-Blockaden, wird über HTTPS aufgelöst). Wenn die URL umleitet, stellen Sie sicher, dass auch das endgültige Ziel öffentlich ist und sich nicht in einem privaten Netzwerk befindet. Code 452 – Upload des konvertierten Bildes fehlgeschlagen (HTTP 500) Die Konvertierung war erfolgreich, aber Ayrshare konnte das konvertierte JPEG nicht in seinem temporären Storage-Bucket ablegen. Dies ist ein interner Fehler auf Ayrshare-Seite und wiederholbar.
Maßnahme: Wiederholen Sie den Beitrag. Wenn der Fehler über mehrere Wiederholungen hinweg bestehen bleibt, wenden Sie sich mit der mediaUrl und dem ungefähren Zeitstempel an den Support.

Transiente YouTube-Upload-Fehler

Die folgenden Fehlercodes liefern spezifische Signale für YouTube-Upload-Fehler, die typischerweise transient sind und sich sicher wiederholen lassen. Beide Antworten enthalten retryAvailable: true, sodass Integrationen auf dieses Boolean und nicht auf den HTTP-Statuscode verzweigen können. Die meisten früheren code: 176-Antworten für YouTube-Uploads werden jetzt auf 453 (transientes Timeout) oder 454 (transient Dienst nicht verfügbar) geleitet, beide mit retryAvailable: true. Wenn Ihre Integration nach HTTP 500 filtert, um YouTube-Uploads zu wiederholen, wechseln Sie zum Filtern auf das Feld retryAvailable im Antwort-Body. Code 453 – YouTube-Upload-Timeout (HTTP 504) Wird zurückgegeben, wenn Googles YouTube-Ingest-Pipeline beim Annehmen des Uploads ein Timeout hatte. Dies ist in der Regel transient und löst sich innerhalb von ein bis zwei Minuten von selbst.
Maßnahme: Wiederholen Sie den Beitrag nach 1–2 Minuten mit exponentiellem Backoff. Verzweigen Sie auf das Feld retryAvailable im Antwort-Body und nicht auf den HTTP-Status, um wiederholbare Fehler zu erkennen. Sie können den retry post-Endpunkt verwenden, um dasselbe Payload erneut zu senden. Code 454 – YouTube-Upload-Dienst vorübergehend nicht verfügbar (HTTP 503) Wird zurückgegeben, wenn YouTubes Upload-Endpunkt einen 5xx-Status zurückgibt oder wenn die Verbindung zu YouTube auf Socket-Ebene zurückgesetzt wurde oder ein Timeout hatte (ECONNRESET, ETIMEDOUT, ESOCKETTIMEDOUT). Diese Zustände sind transient.
Maßnahme: Wiederholen Sie die Anfrage mit exponentiellem Backoff. Verzweigen Sie auf das Feld retryAvailable im Antwort-Body und nicht auf den HTTP-Status, um wiederholbare Fehler zu erkennen.
Wenn der Beitrag auf mehr als eine Plattform abzielte, prüfen Sie postIds, bevor Sie ihn wiederholen. Ein Fehler auf einer Plattform markiert den gesamten Beitrag als Fehler, obwohl die anderen veröffentlicht wurden, und retry post sendet das ursprüngliche Payload erneut an jede Plattform dieses Beitrags – wodurch die erfolgreichen Plattformen ein zweites Mal veröffentlichen würden. Senden Sie stattdessen einen neuen Beitrag für die in errors aufgeführten Plattformen und verwenden Sie retry post nur dann, wenn nichts veröffentlicht wurde.

YouTube-Thumbnail-Fehler Code 307

Code 307 wird zurückgegeben, wenn ein benutzerdefiniertes YouTube-thumbNail nicht angewendet werden kann. Wenn das Video selbst erfolgreich veröffentlicht wird, führt dies nicht zum Fehlschlagen des Beitrags – das YouTube-Ergebnis behält status: "success" und meldet den Fehler zusätzlich in einem warnings-Array (feature: "thumbnail", code: 307). Das ältere thumbnail-Unterobjekt bleibt aus Gründen der Abwärtskompatibilität erhalten. Die häufigste Ursache ist ein nicht verifizierter YouTube-Kanal. Wenn ein Kanal die Telefonverifizierung nicht abgeschlossen hat, gibt YouTube einen Upstream-403 mit der generischen Meldung "The authenticated user doesn't have permissions to upload and set custom video thumbnails" zurück. Dieser Wortlaut klingt nach einem OAuth-Problem, ist in der Praxis aber fast immer ein Verifizierungsproblem, verifizieren Sie also zunächst den Kanal. Ein erneutes Verknüpfen des YouTube-Kontos ist eine zweitrangige Ursache.
Ayrshare validiert das Thumbnail nach Möglichkeit auch vor dem Veröffentlichen: Die Datei muss ein PNG oder JPG/JPEG sein, 2 MB oder weniger groß sein und von einer erreichbaren URL ausgeliefert werden. Ein Thumbnail-Problem lässt den Beitrag niemals scheitern – das Video wird immer veröffentlicht, und der Fehler wird stets als nicht-fataler warnings-Eintrag gemeldet (der übergeordnete status bleibt "success"). Dies gilt unabhängig davon, wann das Problem erkannt wird:
  • Vor dem Upload erkannt. Wenn die Pre-Publish-Validierung eindeutig feststellen kann, dass das Thumbnail ungültig ist (falscher Dateityp, bestätigt über 2 MB oder eine nicht erreichbare URL), überspringt Ayrshare das Thumbnail, veröffentlicht das Video dennoch und meldet den genauen Grund unter warnings – so vermeiden Sie einen zum Scheitern verurteilten Upload-Versuch und erhalten eine klarere Meldung als vom Anbieter zurückgegeben würde.
  • Nach dem Upload erkannt. Wenn der Fehler erst nach der Verarbeitung durch YouTube erkennbar ist (z. B. der 403 bei nicht verifiziertem Kanal oder ein 413 bei einem übergroßen Bild), ist das Video bereits live und der Fehler wird im selben warnings-Array gemeldet.
In beiden Fällen sieht die Antwort wie das oben in diesem Abschnitt gezeigte Beispiel mit status: "success" + warnings aus. Maßnahme: Verifizieren Sie Ihren YouTube-Kanal unter https://www.youtube.com/verify (Telefonverifizierung). Wenn Ihr Kanal bereits verifiziert ist und Thumbnails weiterhin fehlschlagen, trennen und verknüpfen Sie Ihr YouTube-Konto in Social Accounts neu und gewähren Sie alle Berechtigungen. Den vollständigen Leitfaden zur Fehlerbehebung finden Sie unter YouTube Thumbnail Not Applied (Unverified Channel).

Google Business Profile-Autorisierungsfehler

Code 519 – Google Business Profile-Autorisierungsdienst vorübergehend nicht verfügbar (HTTP 503) Wird zurückgegeben, wenn Ayrshare die Aktualisierung des Google-Autorisierungstokens nicht abschließen konnte, weil Googles Token-Endpunkt zu langsam geantwortet oder einen transienten Fehler zurückgegeben hat. Die Aktualisierung wird automatisch wiederholt, bevor dieser Code zurückgegeben wird, und die Antwort enthält retryAvailable: true, sodass Integrationen auf dieses Boolean und nicht auf den HTTP-Statuscode verzweigen können. Das Konto bleibt verbunden – dies ist ein vorübergehender Zustand von Googles Autorisierungsdienst, keine defekte Verbindung. Jede Google Business Profile-Operation aktualisiert zuerst die Autorisierung, daher kann jede von ihnen diesen Code zurückgeben – das Veröffentlichen eines Beitrags, das Lesen des Beitragsverlaufs, das Aktualisieren von Standortdaten, das Abrufen des verbundenen Kontos, das Auflisten von Bewertungen und das Beantworten einer Bewertung. Die meisten früheren code: 227-Antworten auf diesen Pfaden werden jetzt auf 519 mit retryAvailable: true geleitet. Code 227 fordert den Benutzer auf, das Konto neu zu verbinden, was einen transienten Aktualisierungsfehler nie behoben hat – die Autorisierung selbst war durchgehend intakt. Wenn Ihre Integration nach 227 filtert, um zu einem erneuten Verknüpfen von Google Business Profile aufzufordern, wechseln Sie stattdessen zum Verzweigen auf das Feld retryAvailable im Antwort-Body und wiederholen Sie mit Backoff.
details enthält den von Google gemeldeten Grund oder – wenn die Aktualisierung lokal ohne Antwort-Body von Google ein Timeout hatte – eine Zusammenfassung der unternommenen Versuche und der verstrichenen Zeit. Maßnahme: Wiederholen Sie die Anfrage mit exponentiellem Backoff. Verzweigen Sie auf das Feld retryAvailable im Antwort-Body und nicht auf den HTTP-Status, um wiederholbare Fehler zu erkennen.
Prüfen Sie bei einem fehlgeschlagenen Cross-Post zuerst postIds und errors; wenn eine andere Plattform bereits erfolgreich war, wiederholen Sie nur die fehlgeschlagene GMB-Plattform, statt das vollständige Payload erneut zu senden – retry post sendet das ursprüngliche Payload erneut an jede Plattform dieses Beitrags, wodurch die erfolgreichen Plattformen ein zweites Mal veröffentlichen würden. Bei einem vollständig fehlgeschlagenen Beitrag können Sie den retry post-Endpunkt verwenden, um dasselbe Payload erneut zu senden.

Pinterest-AI-Offenlegungswarnung

Code 521 – Pinterest-AI-Offenlegungen nicht angewendet (HTTP 200) Warnung, kein Fehler. Wird zurückgegeben, wenn pinterestOptions.aiDisclosures ungültig ist, zum Beispiel bei einem unbekannten Wert oder falscher Groß-/Kleinschreibung. Über die REST API gibt auch ein Wert, der kein Array von Strings ist, 521 zurück. Der Pin wird trotzdem veröffentlicht, aber Ayrshare sendet keine AI-Offenlegung an Pinterest. Der MCP-Server und die GraphQL API prüfen zuerst die Werttypen, sodass fehlerhafte Werte wie eine Liste mit einer Zahl dort vor dem Veröffentlichen abgelehnt werden. Die Warnung kommt im Pinterest-Eintrag unter postIds[].warnings[] an, nicht in errors[], und trägt feature: "pinterestOptions.aiDisclosures". Akzeptierte Werte sind AI_MODIFIED und SYNTHETIC_PERFORMER.

Reddit-Veröffentlichungsfehler

Code 442 – Reddit gesperrtes Subreddit (HTTP 400) Wird zurückgegeben, wenn das Konto vom Posten im Ziel-Subreddit gesperrt wurde. Dies ist nicht wiederholbar – der Beitrag wird nicht erfolgreich sein, wenn er unverändert erneut gesendet wird. Die Meldung enthält den Namen des betroffenen Subreddits (zum Beispiel r/news).
Maßnahme: Entfernen Sie das gesperrte Subreddit aus Ihren Ziel-Subreddits. Ein unverändertes erneutes Senden des Beitrags wird nicht erfolgreich sein. Code 443 – Reddit nicht erlaubtes Wort im Titel (HTTP 400) Wird zurückgegeben, wenn ein Subreddit den Beitrag ablehnt, weil sein Titel ein nicht erlaubtes Wort enthält. Bearbeiten Sie den Titel vor dem erneuten Senden – ein unverändertes erneutes Senden wird nicht erfolgreich sein. Die Meldung enthält den Namen des betroffenen Subreddits (zum Beispiel r/news).
Maßnahme: Bearbeiten Sie den Beitragstitel, um das nicht erlaubte Wort zu entfernen, und wiederholen Sie dann.

Moderationsfehler

Code 438 – Moderations-Eingabe abgelehnt (HTTP 400) Wird von POST /validate/moderation zurückgegeben, wenn der KI-Anbieter die bereitgestellte Eingabe ablehnt – zum Beispiel einen nicht unterstützten Dateityp. Dies ist ein Eingabeproblem der Anfrage, kein vorübergehender Verarbeitungsfehler.
Maßnahme: Prüfen Sie, ob die Moderations-Eingabe gültig ist und einen unterstützten Dateityp verwendet, und senden Sie sie dann erneut.
Vergleichen Sie Code 438 mit Code 331. Code 331 deckt dasselbe Moderationsszenario ab, stellt aber einen echten Verarbeitungsfehler auf Anbieterseite dar (HTTP 500, Meldung „There was an issue with the AI processing. Please try again.”). Code 331 ist ein transienter serverseitiger Fehler, den Sie wiederholen können, während Code 438 anzeigt, dass die Eingabe selbst abgelehnt wurde und vor dem erneuten Versuch korrigiert werden muss.

LinkedIn-Fehler bei der Autorisierungsaktualisierung

Code 524 – LinkedIn-Token-Aktualisierung abgelehnt (HTTP 500) Wird zurückgegeben, wenn LinkedIn die Aktualisierung der Autorisierung wegen eines Problems mit der LinkedIn-Konfiguration der Anwendung ablehnt, nicht wegen des Kontos des Benutzers. Die LinkedIn-Verbindung des Benutzers ist weiterhin gültig, daher behebt ein erneutes Verknüpfen das Problem nicht. Die Antwort enthält kein Feld resolution.relink und liefert retryAvailable: false, weil ein erneuter Versuch das Problem nicht behebt. Jeder LinkedIn-Vorgang, der zuerst die Autorisierung aktualisiert, kann diesen Code zurückgeben, zum Beispiel das Veröffentlichen eines Beitrags nach Ablauf des Zugriffstokens.
Maßnahme: Wenden Sie sich mit den Anfragedetails an den Ayrshare-Support. Bitten Sie den Benutzer nicht, LinkedIn neu zu verknüpfen. Ein erneutes Verknüpfen hilft nicht, und das Entfernen von Ayrshare in den Einstellungen von LinkedIn selbst widerruft den Zugriff des Benutzers für jedes Profil, das er verbunden hat.
Wenn LinkedIn die Aktualisierung aus einem vorübergehenden Grund wiederholt ablehnt, versucht Ayrshare es erneut und gibt stattdessen Code 119 („There was an issue connecting with LinkedIn. Please try again.“) zurück. Bei Code 119 können Sie es später gefahrlos erneut versuchen; Code 524 lässt sich durch erneute Versuche nicht beheben.

LinkedIn-Analytics-Fehler

Code 475 – LinkedIn-Profil für Analytics neu verknüpfen (HTTP 403) Wird von POST /analytics/post und POST /analytics/social für ein persönliches (Member-)LinkedIn-Profil zurückgegeben, das verknüpft wurde, bevor Member-Analytics veröffentlicht wurden. Diesen Profilen fehlen die LinkedIn-Member-Analytics-Scopes (r_member_postAnalytics, r_member_profileAnalytics), sodass LinkedIn die Analytics-Anfrage ablehnt. Das Posten ist davon nicht betroffen.
Maßnahme: Lassen Sie den Kontoinhaber sein LinkedIn-Profil in Social Accounts neu verknüpfen, um die neuen Analytics-Scopes zu gewähren, und wiederholen Sie dann die Analytics-Anfrage. Nach der erneuten Verknüpfung dauert es einige Minuten, bis der Fehler behoben ist: Ayrshare speichert diesen Fehler kurz im Cache, und LinkedIn cacht auch die Berechtigungen des Tokens, sodass ein neu verknüpftes Profil bis zu ca. 5–10 Minuten lang weiterhin Code 475 zurückgeben kann, bevor Analytics gelingt.

TikTok-Kommentarfehler

Code 288 – TikTok-Kommentar verschoben / Beitrag wird noch verarbeitet (HTTP 400) TikTok verarbeitet Videos asynchron, daher ist die id eines frisch veröffentlichten Beitrags "pending", bis TikToks Webhook post.publish.publicly_available die tatsächliche Video-ID auflöst. Eine get-comments-, Kommentar- oder Antwortanfrage gegen einen Beitrag, der noch verarbeitet wird (oder dessen id "failed" ist), wird vor jedem Aufruf an TikTok abgelehnt und gibt Code 288 anstelle eines generischen Fehlers zurück.
Maßnahme: Warten Sie, bis TikTok die Verarbeitung abgeschlossen hat, und wiederholen Sie dann. Hören Sie auf den Scheduled Action Webhook tikTokPublished oder pollen Sie /history, bis die id des Beitrags die aufgelöste numerische Video-ID ist. Ein first comment wird automatisch gepostet, sobald der Beitrag aufgelöst ist, sodass er nicht erneut ausgeführt werden muss. Bei einem "failed"-Beitrag weist die Meldung stattdessen darauf hin, dass das Video nicht veröffentlicht werden konnte und die Aktion nicht ausgeführt wird.

Abgelaufene oder nicht verfügbare Story-Fehler

Code 485 – Instagram-/Facebook-Story-Kommentare und Instagram-Story-Analytics (HTTP 404 als repräsentativer) Stories können nach ihrem Verfügbarkeitsfenster ablaufen oder nicht mehr verfügbar sein. Nach diesem Fenster können Kommentare oder Insights nicht mehr abgerufen werden. Code 485 kennzeichnet:
  • abgelaufene oder nicht verfügbare Instagram- und Facebook-Story-Zweige von get-comments; und
  • einen abgelaufenen oder nicht verfügbaren Instagram-Story-Zweig von POST /analytics/post.
Facebook-Story-Analytics sind nicht verfügbar und werden von Code 485 nicht erfasst. Clients sollten den numerischen code abgleichen, nicht den exakten Meldungstext, der variieren oder übersetzt sein kann. Bei einem plattformübergreifenden Read, bei dem mindestens eine andere Plattform erfolgreich ist, erscheint der fehlgeschlagene Zweig im obersten errors[]-Array, während die intakten Plattformen normal zurückgegeben werden. Die Gesamtantwort ist HTTP 200 mit obersten status: "partial" (siehe Multiplattform-Reads & Teilerfolg für Kommentare und Analytics).

Get-Comments-Teilerfolgs-Beispiel

Post-Analytics-Teilerfolgs-Beispiel

Wenn alle Plattformen fehlschlagen, hat die Antwort obersten status: "error" und enthält das vollständige errors[]-Array. Der repräsentative Code 485 wird auf HTTP 404 abgebildet; andere repräsentative Codes verwenden ihre eigenen HTTP-Zuordnungen. Maßnahme: Behandeln Sie Code 485 als Signal, dass die angeforderten Story-Kommentare oder Insights nicht abgerufen werden können. Gleichen Sie den Code ab, statt aus dem Meldungstext Schlussfolgerungen zu dauerhaftem Fehlschlag, Wiederholbarkeit oder Kontoverknüpfung zu ziehen.

Übersetzung von Fehlermeldungen

Die API-Fehlermeldungsantwort kann automatisch in die Sprache Ihrer Wahl übersetzt werden. Dies ist nützlich, wenn Sie den Fehler direkt Ihrem Nutzer in seiner bevorzugten Sprache anzeigen möchten. Siehe hier, wenn Sie die Sprache der Social-Linking-Seite wählen möchten. Fügen Sie im Header Folgendes hinzu:
Wobei Language_Code einer der verfügbaren Sprachcodes ist. Zum Beispiel übersetzt Folgendes den Fehler ins Französische.
Unser System erkennt die Sprache der Fehlermeldung automatisch.