Zum Hauptinhalt springen
Die X API stellt die folgenden Antwort- und Fehlercodes bereit, um das Verständnis und die Fehlersuche in Echtzeit zu unterstützen. Nutzen Sie den Debugging-Leitfaden und den unten stehenden Fehlerindex für zusätzlichen Kontext. Erfolgreiche Antworten werden durch einen HTTP-Statuscode aus der 200er‑Serie und eine JSON‑basierte Nutzlast gekennzeichnet, die die angeforderten, erstellten, geänderten oder gelöschten Objekte enthält, zusammen mit einer Darstellung der Interpretation Ihrer Anfrage durch den Server. Fehlerantworten werden mit einem HTTP‑Statuscode außerhalb der 200er‑Serie zurückgegeben. Unterschiedliche Fehlercodes weisen auf unterschiedliche Ursachen hin. Die X API versucht, für jede Anfrage geeignete HTTP-Statuscodes zurückzugeben.

​
X API v2 HTTP-Statuscodes

CodeTextBeschreibungTipps zur Fehlerbehebung
200OKDie Anfrage war erfolgreich!
400Bad RequestDie Anfrage war ungültig oder kann nicht verarbeitet werden. Eine dazugehörige Fehlermeldung erläutert die Details. Anfragen ohne Authentifizierung oder mit ungültigen query-Parametern gelten als ungültig und führen zu dieser Antwort.Überprüfen Sie das Format Ihrer JSON-Abfrage. Wenn Ihre Regel beispielsweise doppelte Anführungszeichen enthält, die mit einem Exact-Match- oder einem anderen Operator verknüpft sind, müssen Sie diese möglicherweise mit einem Backslash maskieren, um sie von der Struktur des JSON-Formats zu unterscheiden.
401UnauthorizedEs gab ein Problem bei der Authentifizierung Ihrer Anfrage. Dies kann auf fehlende oder falsche Authentifizierungsdaten zurückzuführen sein. Dies kann auch in anderen, nicht näher definierten Umständen zurückgegeben werden.Prüfen Sie, ob Sie die richtige Authentifizierungsmethode verwenden und ob Ihre Zugangsdaten korrekt sind.
403ForbiddenDie Anfrage wurde verstanden, aber abgelehnt, oder der Zugriff ist nicht erlaubt. Eine dazugehörige Fehlermeldung erklärt den Grund.Prüfen Sie, ob Ihr Developer-Konto Zugriff auf das Endpoint hat, das Sie verwenden möchten. Möglicherweise muss Ihre App allowgelistet werden (z. B. Engagement API oder Ads API), oder Sie müssen Zugriff beantragen.
404Not FoundDie angeforderte URI ist ungültig, oder die angeforderte Ressource, z. B. ein Benutzer, existiert nicht.Prüfen Sie, ob Sie gültige Parameter und die korrekte URI für das von Ihnen verwendete Endpoint verwenden.
409Connection ExceptionWird zurückgegeben, wenn versucht wird, eine Verbindung zu einem Filtered stream ohne Regeln herzustellen.Prüfen Sie, ob Sie mindestens eine Regel für den Stream erstellt haben, zu dem Sie eine Verbindung herstellen. Filtered stream liefert nur Posts, die einer aktiven Regel entsprechen. Wenn es keine Regeln gibt, liefert der Stream keine Posts.
429Too Many RequestsWird zurückgegeben, wenn eine Anfrage aufgrund der Rate Limit der App oder eines ausgeschöpften Post cap nicht bedient werden kann. Siehe Rate Limiting.Prüfen Sie die Anzahl der Anfragen pro Zeitraum, die mit dem von Ihnen verwendeten Endpoint zulässig sind. Warten Sie, bis der Zeitraum zurückgesetzt wird. Verteilen Sie Ihre Anfragen, um zu vermeiden, dass Sie an Rate Limits stoßen, oder upgraden Sie auf den nächsten verfügbaren Datentarif.
500Internal Server ErrorEtwas ist kaputt. Dies ist in der Regel ein vorübergehender Fehler, zum Beispiel bei hoher Last oder wenn ein Endpoint vorübergehend Probleme hat.Prüfen Sie die X API-Statusseite oder das Developer-Community-Forum, falls andere ähnliche Probleme haben, oder warten Sie einfach und versuchen Sie es später erneut.
501UnimplementedDie X API unterstützt dieses Endpoint nicht und kann die Anfrage nicht erfüllen.
503Service UnavailableDie X-Server sind erreichbar, aber mit Anfragen überlastet. Versuchen Sie es später erneut.Prüfen Sie die X API-Statusseite oder das Developer-Community-Forum, falls andere ähnliche Probleme haben, oder warten Sie einfach und versuchen Sie es später erneut.
Wenn bei einer Anfrage ein Fehler auftritt, werden im Response-Body detaillierte Informationen zum Fehler zurückgegeben, um die Diagnose zu unterstützen. Ein type-Feld, das eine URI ist, gibt die Art des Problems an, während zusätzliche Felder Details bereitstellen. Die Felder type, title und detail werden in diesen Bodies immer zurückgegeben (siehe Tabelle unten). Zusätzliche Felder, wie im Beispiel unten, variieren je nach Art des Fehlers. 
{
  "client_id": "101010101",
  "required_enrollment": "Standard Basic",
  "registration_url": "https://developer.twitter.com/en/account",
  "title": "Client nicht zulässig",
  "detail": "Diese Anfrage muss mit einem genehmigten Developer-Konto gestellt werden, das für das angeforderte endpoint registriert ist. Weitere Informationen finden Sie in unserer Dokumentation.",
  "reason": "client-not-enrolled",
  "type": "https://api.x.com/2/problems/client-forbidden"
}

​
Partielle Fehler

In einigen Fällen können die oben beschriebenen Fehler in einer Antwort auftreten, die den Statuscode 200 zurückgegeben hat. In diesen Fällen ist das endpoint so konzipiert, dass es die data zurückgibt, die es liefern kann, und gleichzeitig detaillierte Fehler zu dem bereitstellt, was nicht zurückgegeben werden konnte. Zum Beispiel ermöglicht das Posts lookup endpoint einer X Developer-App, mehr als eine id anzufordern. Wenn einige dieser Posts verfügbar sind, einer davon jedoch gelöscht wurde, werden die verfügbaren Posts im data-Feld der Antwort zurückgegeben. Zusätzlich wird ein errors-Feld in der Payload zurückgegeben, das angibt, welche angeforderten Post(s) nicht zurückgegeben werden konnten. Dasselbe Format wird wie bei vollständigen Anforderungsfehlern verwendet, um die Diagnose von Problemen zu erleichtern.

​
Fehlerinformationen

Jeder Problemtyp beschreibt die Art des aufgetretenen Problems. Eine vollständige Liste möglicher Probleme finden Sie ebenfalls in unserer API-Spezifikation. Die X API versucht, für jede Anfrage die passenden HTTP-Statuscodes zurückzugeben.
TitelTypBeschreibung
Allgemeines Problemabout:blankEin allgemeines Problem ohne zusätzliche Informationen über die durch den HTTP-Statuscode bereitgestellten hinaus.
Ungültige Anfragehttps://api.X.com/2/problems/invalid-requestEin Problem, das darauf hinweist, dass diese Anfrage ungültig ist. Wenn Ihre Anfrage einen POST-Body enthält, stellen Sie sicher, dass der Inhalt gültiges JSON ist und der OpenAPI-Spezifikation entspricht.
Ressource nicht gefundenhttps://api.X.com/2/problems/resource-not-foundEin Problem, das darauf hinweist, dass ein bestimmter Post, User usw. nicht existiert.
Nicht autorisiert für Ressourcehttps://api.X.com/2/problems/not-authorized-for-resourceEin Problem, das darauf hinweist, dass Sie einen bestimmten Post, User usw. nicht sehen dürfen.
Client nicht zulässighttps://api.X.com/2/problems/client-forbiddenEin Problem, das darauf hinweist, dass Ihr Client diese Anfrage nicht stellen darf.
Nicht zulässige Ressourcehttps://api.X.com/2/problems/disallowed-resourceEin Problem, das darauf hinweist, dass die angeforderte Ressource den Grundsätzen dieser API widerspricht.
Nicht unterstützte Authentifizierunghttps://api.X.com/2/problems/unsupported-authenticationEin Problem, das darauf hinweist, dass die verwendete Authentifizierung nicht unterstützt wird.
Nutzungslimit überschrittenhttps://api.X.com/2/problems/usage-cappedEin Problem, das darauf hinweist, dass ein Nutzungslimit überschritten wurde.
Verbindungsproblemhttps://api.X.com/2/problems/streaming-connectionEin Problem, das darauf hinweist, dass etwas mit der Verbindung nicht stimmt.
Client getrennthttps://api.X.com/2/problems/client-disconnectedIhr Client ist nicht mehr verbunden.
Betriebliche Trennunghttps://api.X.com/2/problems/operational-disconnectSie wurden aus betrieblichen Gründen getrennt.
Regelanzahl überschrittenhttps://api.X.com/2/problems/rule-capSie haben die maximale Anzahl von Regeln überschritten.
Regel-Längenüberschreitunghttps://api.X.com/2/problems/rule-lengthSie haben abhängig von Ihrer Zugriffsstufe die maximale Anzahl von Zeichen für Ihre query oder Regel überschritten. Siehe Zugriffsebenen.
Ungültige Regelnhttps://api.X.com/2/problems/invalid-rulesDie von Ihnen übermittelte Regel ist ungültig.
Doppelte Regelnhttps://api.X.com/2/problems/duplicate-rulesDie von Ihnen übermittelte Regel ist ein Duplikat.

​
Tipps zur Fehlerbehebung

Beim Erstellen einer Anwendung ist es normal, gelegentlich auf Fehler oder unerwartete Probleme zu stoßen. Im Folgenden finden Sie einige Tipps, wie Sie Ihren Code debuggen können:Beginnen Sie damit, das Problem in kleinere Teile zu zerlegen, um herauszufinden, wo es liegt. Wenn Sie beispielsweise ein REST- oder ein Streaming-endpoint integrieren, kann das Problem an einem der folgenden Punkte liegen:
  • Der endpoint erfordert eine korrekte Authentifizierung.
  • Der endpoint erfordert gültige Parameter und Header. Etwaige Filterregeln werden mit den richtigen Operatoren und der korrekten Syntax erstellt.
  • Die URI des endpoint muss korrekt sein und im Fall von REST-endpoints muss die richtige HTTP-Methode verwendet werden.
  • Die data oder Ressource, auf die Sie zugreifen möchten, ist für Sie nicht zugänglich (zum Beispiel sind private data nur für authentifizierte Nutzer verfügbar).
  • Ihr aktuelles data-Paket gewährt Ihnen nur für bestimmte endpoints und spezifische Rate Limits Zugriff. Weitere Details finden Sie in Ihrem Entwicklerportal.
  • Ihr Code verwendet eine Bibliothek eines Drittanbieters, um den endpoint in Ihren Code zu integrieren.
  • Ihr Code muss die Antwort des endpoint erfolgreich parsen.
Lesen Sie die zugehörige Fehlermeldung. Diese sollte Ihnen einen guten Hinweis darauf geben, worin das Problem besteht. Verwenden Sie die Tabellen im Abschnitt zu Fehler- und Antwortcodes für konkrete Tipps zur Fehlerbehebung zu jedem Fehlercode.Für REST-endpoints können Sie einen REST-Client wie Postman oder Insomnia verwenden, um die Schritte (1) bis (5) oben zu validieren (sehen Sie sich unseren Leitfaden “Erste Schritte mit Postman” an). Wenn die Anfrage mit dem REST-Client einen 200-Erfolgsstatuscode zurückgibt, können Sie davon ausgehen, dass das Problem bei Ihrem Code oder der von Ihnen verwendeten Bibliothek liegt – nicht bei der endpoint-Anfrage selbst.Für Streaming-endpoints können Sie cURL (ein Befehlszeilentool zum Senden oder Empfangen von Anfragen mithilfe der URL-Syntax) verwenden, um zu prüfen, ob das Problem bei der Anfrage an den endpoint liegt (Schritte (1) bis (5) oben) oder bei Ihrem Code selbst (Schritte (6) bis (7) oben).
  • Prüfen Sie, ob Sie die für den endpoint erforderliche Authentifizierungsmethode verwenden. Dies lässt sich über die API-Referenzseite des endpoint feststellen.
  • Prüfen Sie, ob Ihre Authentifizierungsdaten korrekt sind. Sie können Ihre App Keys und Tokens im Apps-Bereich Ihres Entwickler-Dashboards (unter „Details“) überprüfen oder neu generieren.
  • Prüfen Sie, ob Sie Ihre OAuth 1.0a-Anfrage ordnungsgemäß autorisiert haben – mit oauth_nonce, oauth_signature und oauth_timestamp für Ihre Anfrage.
  • Wenn das Problem weiterhin besteht, ziehen Sie eine OAuth-Bibliothek, einen REST-Client wie Postman oder Insomnia oder xurl in Betracht.
Lesen Sie unseren Leitfaden zur Authentifizierung für weitere Informationen zu allen oben genannten Punkten.
Ein 429-Fehler kann auftreten, wenn Sie das Rate Limit für ein bestimmtes Endpoint erreichen oder wenn Sie die Post cap erreichen.Wenn der spezifische Fehler „Too many requests“ zurückgegeben wird, haben Sie das Rate Limit des Endpoints erreicht. Anders ausgedrückt: Sie haben die maximale Anzahl von Anfragen überschritten, die für ein Endpoint pro festgelegtem Zeitraum erlaubt sind.Beachten Sie, dass Rate Limits auf App- und Benutzer-Ebene festgelegt sind.
  • X App-Ebene gibt die Anzahl der zulässigen Anfragen bei Verwendung von OAuth 2.0 App-Only an, wobei Rate Limits global für die gesamte App gelten. Wenn eine Methode beispielsweise 15 Anfragen pro Rate-Limit-Fenster zulässt, können Sie 15 Anfragen pro Fenster im Namen Ihrer X App stellen. Dieses Limit ist vollständig getrennt vom Benutzer-Level-Limit zu betrachten. Weitere Informationen finden Sie in unserem Leitfaden zu OAuth 2.0 App-Only.
  • Benutzerkontext-Ebene gibt die Anzahl der Anfragen an, die pro Benutzer-Access Token bei Verwendung von OAuth 1.0a User Context oder OAuth 2.0 Authorization Code mit PKCE gestellt werden können. Wenn eine Methode beispielsweise 15 Anfragen pro Rate-Limit-Fenster zulässt, erlaubt sie 15 Anfragen pro Fenster und pro Benutzer-Access Token. Lesen Sie mehr in unserem Leitfaden dazu, wie Sie die Access Tokens eines Nutzers mit OAuth 1.0a und OAuth 2.0 erhalten.
Beginnen Sie damit, die Rate Limits für das von Ihnen verwendete Endpoint zu prüfen. Sie finden diese Informationen auf der API-Referenzseite des Endpoints und im neuen Dashboard des Entwicklerportals.Lesen Sie unsere Dokumentation für weitere Informationen zu Rate Limits, einschließlich der Nutzung von HTTP-Headern, um nachzuverfolgen, wo Ihre App in Bezug auf ein bestimmtes Rate Limit steht, wie Sie sich von einem 429-Fehler aufgrund eines Rate Limits erholen und Tipps, um zu vermeiden, überhaupt rate-limited zu werden:Wenn Sie den spezifischen Fehler „Usage cap exceeded: Monthly product cap“ erhalten haben, bedeutet das, dass Sie die Post cap für Ihre Zugriffsebene erreicht haben. Ausführliche Details dazu, was diese Post caps sind, finden Sie auf unserer Dokumentationsseite.
Befolgen Sie die folgenden Schritte, wenn Sie erwartet haben, dass ein Post zurückgegeben wird, er aber nicht vom Endpoint geliefert wurde.
  • Überprüfen Sie Ihre Regel, um sicherzustellen, dass Sie die richtigen operators und die richtige syntax verwenden. Teilen Sie die Regel in kleinere Klauseln auf, um sicherzustellen, dass Sie die korrekte Syntax verwenden.
  • Wenn das Konto, von dem der Post gesendet wurde, zum Zeitpunkt der Erstellung des Posts protected war, wird der Post nicht zurückgegeben – selbst wenn das Konto zum Zeitpunkt der Anfrage an das Endpoint öffentlich ist. Dies können Sie in der Regel mit der X Advanced Search prüfen: Wenn ein Post mit der X-Advanced-Search-Funktionalität nicht angezeigt wird, sollten Sie davon ausgehen, dass er vom Endpoint nicht zurückgegeben wird.
Die folgenden Schritte gelten nur für Streaming-Endpoints:
  • Waren Sie mit dem Stream verbunden, als der Post gesendet wurde? Denken Sie daran, dass der im Post-Objekt gelieferte Zeitstempel die Zeit in UTC angibt. Wenn es zum Zeitpunkt des Posts zu einer Trennung kam, prüfen Sie die verfügbaren Recovery- und Redundanzfunktionen, um verpasste data nachzufüllen.
  • War Ihre Regel aktiv, als der Post gesendet wurde? Denken Sie daran, dass der im Post-Objekt gelieferte Zeitstempel die Zeit in UTC angibt.
Sie können einen der folgenden Fehler erhalten, wenn Ihr Stream nicht mit der Geschwindigkeit Schritt hält, mit der wir Daten liefern, und Ihre App die Daten aus dem Stream nicht schnell genug verarbeitet:
This stream has been disconnected because your client was unable to keep up with us.

This stream has been disconnected for operational reasons.
Wir lassen zu, dass die Zustellung für eine gewisse Zeit zurückliegt, und halten auf unserer Seite für jeden Stream einen temporären Staging-Puffer vor; wenn Sie jedoch nicht aufholen, leiten wir eine Trennung ein, damit Sie sich zum aktuellen Zeitpunkt erneut verbinden können. Bitte beachten Sie, dass dies zu Datenverlust führen kann (für Daten, die sich zum Zeitpunkt des vollständigen Pufferabbruchs im Puffer befinden).Dies kann bei starken Daten-Spitzen auftreten. Generell empfehlen wir, einen separaten Puffer-Mechanismus für die schnelle Datenaufnahme zu verwenden, der vom eigentlichen Verarbeitungsprozess getrennt ist.Wenn Sie Enterprise-Kunde sind und v1.1 endpoints verwenden, erfahren Sie in unseren Artikeln zu connection sowie zum Konsumieren von Streaming-Daten hier und hier mehr darüber, wie Sie Ihre App optimieren können, um solche Verbindungsabbrüche zu verhindern.Es steht eine Reihe von Tools zur Verfügung, um verpasste Posts aufgrund eines Verbindungsabbruchs abzurufen, einschließlich der unten aufgeführten. Beachten Sie, dass die folgenden Tools nur mit v1.1 endpoints auf Enterprise-Zugriffsebene verfügbar sind.
  • Redundant Connections - Mit mehreren Verbindungen den Stream von mehreren Servern beziehen, um Datenverluste zu vermeiden, wenn eine Verbindung getrennt wird.
  • Replay - Daten aus den letzten 5 Tagen über einen separaten Stream wiederherstellen.
  • Backfill - Innerhalb von 5 Minuten erneut verbinden und an der zuletzt verarbeiteten Stelle fortsetzen.
  • Historical PowerTrack - Daten aus dem gesamten X-Archiv wiederherstellen.

​
Hilfe erhalten

Das X Community-Forum steht Ihnen zur Verfügung, um technische Fragen zur X Developer Platform zu stellen. Dies ist ein Diskussionsforum, in dem Sie Fragen anderer Entwickler sowie technische Informationen zu einer Vielzahl von Themen rund um die Nutzung der X API finden. Wir laden Sie ein, sich an den Diskussionen zu beteiligen, indem Sie auf Fragen antworten und sich in unserem Forum austauschen. Auch Mitarbeitende von X sind dort, um Unterstützung zu leisten.

​
Bevor Sie eine Frage posten

  • Durchsuchen Sie die X Developer-Dokumentation nach Informationen zu Ihrem Problem
  • Suchen Sie im Community-Forum nach ähnlichen Fragen anderer Entwickler
  • Lesen Sie die Richtlinien des Community-Forums

​
Wenn Sie eine Frage posten, stellen Sie bitte sicher, dass Sie die folgenden Informationen angeben

  • Eine Beschreibung des Problems
  • Den ausgeführten API-Aufruf (nach Möglichkeit mit Headern)
  • Die zurückgegebene X-Antwort (einschließlich etwaiger Fehlermeldungen)
  • Was Sie stattdessen zu erhalten erwartet hätten
  • Liste der durchgeführten Schritte zur Fehlerbehebung
  • Liste der Schritte, die zum Reproduzieren des Problems erforderlich sind
  • Falls relevant, der Zeitraum, in dem das Problem auftrat
  • Falls relevant, die App-ID, Post-ID usw.
  • Relevante Codebeispiele oder Screenshots
Bitte fügen Sie pro Post nur ein Thema bzw. eine Frage hinzu. Wenn Sie Funktionswünsche oder Feedback haben, reichen Sie diese bitte über das X Developer Platform Feedback Form ein. Bei richtlinienbezogenen Problemen, z. B. einer App-Sperrung, wenden Sie sich bitte an den Policy-Support. Bei X-bezogenen Problemen, z. B. Login- und Kontosupport, verwenden Sie bitte den X Help Desk.
⌘I