Compliance Firehose API

Bitte beachten

Wir haben ein neues Compliance-Tool für die X API v2 veröffentlicht: Batch-Compliance. Mit diesem Tool können Sie große Datensätze mit Post- oder Benutzer-IDs hochladen, um deren Compliance-Status abzurufen und so festzustellen, welche Daten Maßnahmen erfordern, damit Ihre Datensätze den Vorgaben entsprechen.

Außerdem wurden sowohl Batch-Compliance als auch der Compliance-Firehose aktualisiert, um Post-Änderungen zu unterstützen. Für den Compliance-Firehose wurde ein neues Ereignis „tweet_edit“ hinzugefügt. Weitere Details finden Sie in der Dokumentation zu den Compliance-Datenobjekten. Erfahren Sie auf der Seite Grundlagen zu Post-Änderungen mehr darüber, wie die Edit-Post-Metadaten funktionieren.

​

Übersicht

Enterprise

Einer der zentralen Werte von X ist es, die Stimme der Nutzer zu verteidigen und zu respektieren. Dazu gehört, ihre Erwartungen und Absichten zu achten, wenn sie Inhalte, die sie auf X teilen, löschen, ändern oder bearbeiten. Wir sind der Meinung, dass dies für die langfristige Gesundheit einer der größten öffentlichen Echtzeit‑Informationsplattformen der Welt von entscheidender Bedeutung ist. X legt die Kontrolle in die Hände seiner Nutzer und gibt Einzelpersonen die Möglichkeit, ihre eigene X‑Erfahrung zu steuern. Wir sind der Ansicht, dass Geschäftskunden, die X data erhalten, die Verantwortung tragen, die Erwartungen und Absichten der Endnutzer zu respektieren.

Weitere Informationen zu den Arten von Compliance‑Ereignissen, die auf der X Plattform möglich sind, finden Sie in unserem Artikel Honoring User Intent on X.

Jeder Entwickler oder jedes Unternehmen, das X data über eine API nutzt, ist verpflichtet, alle zumutbaren Anstrengungen zu unternehmen, um Änderungen an nutzergenerierten Inhalten zu berücksichtigen. Diese Verpflichtung erstreckt sich auf Nutzerereignisse wie Löschungen, Modifikationen und Änderungen von Freigabeoptionen (z. B. wenn Inhalte geschützt oder zurückgehalten werden). Dies gilt auch, wenn Nutzer ihre Posts bearbeiten. Bitte beachten Sie die spezifische Formulierung in der Developer Policy und/oder in Ihrem X Data Agreement, um zu verstehen, wie sich diese Verpflichtung auf Ihre Nutzung von X data auswirkt.

X bietet die folgenden Lösungen, die Informationen über diese Nutzer‑Compliance‑Ereignisse liefern und darüber, ob ein bestimmter Post oder Nutzer öffentlich verfügbar ist oder nicht. Nachfolgend finden Sie einen kurzen Überblick über die Lösungen und ihre allgemeinen Integrationsmuster:

​

GET statuses/lookup und GET users/lookup

• Format: REST-API. Siehe: GET statuses/lookup und GET users/lookup.

• Diese Endpoints geben stets die neueste Version aller Post-Bearbeitungen zurück. Alle Post-Objekte, die Posts beschreiben, die nach der Einführung der Bearbeitungsfunktion erstellt wurden, enthalten Post-Bearbeitungsmetadata. Dies gilt auch für Posts, die nicht bearbeitet wurden.

• Für alle Posts gilt: Anfragen, die mehr als 30 Minuten nach ihrer Erstellung gestellt werden, geben den finalen Zustand der Posts wieder.

• Liefern Verfügbarkeitsinformationen für bestimmte Posts oder Nutzer, wie vom Aufrufer im Rahmen der API-Anfrage definiert.

• Kann für Ad-hoc-Stichproben des aktuellen Verfügbarkeitsstatus einer bestimmten Gruppe von Posts/Nutzern verwendet werden.

• Ideal für Kunden, die den aktuellen Zustand eines bestimmten Posts oder Nutzers zu einem gegebenen Zeitpunkt prüfen müssen.

• Diese APIs bieten einen hilfreichen Mechanismus für Kunden, die die Verfügbarkeit eines Inhalts prüfen müssen, etwa wenn:

  1. Posts angezeigt werden
  2. in einer 1:1-Interaktion mit einem Post oder Nutzer interagiert wird
  3. X Inhalte über einen zulässigen Datei-Download an einen Dritten verteilt werden
  4. Posts über längere Zeiträume gespeichert werden

​

Compliance Firehose (nur Enterprise)

• Format: Streaming-API. Siehe: Compliance Firehose.
• Liefert einen Echtzeit-Stream von Compliance-Aktivitäten auf X. Zu diesen Aktivitäten gehört auch das Bearbeiten von Posts.
• Kann verwendet werden, um den Compliance-Status für einen Bestand gespeicherter data aufrechtzuerhalten, wenn neue Compliance-Ereignisse auf der Plattform auftreten.
• Ideal für Kundinnen und Kunden, die große Mengen an X data über längere Zeiträume verarbeiten und speichern.

​

Leitfäden

​

Bewährte Compliance-Praktiken

​

Empfehlungen & Best Practices

• Entwerfen Sie Datenspeicherschemata, die numerische Post-ID und User-ID speichern: Nachrichten eines Users erfordern Maßnahmen für alle Posts dieses Users. Da alle Compliance-Nachrichten ausschließlich über numerische IDs zugestellt werden, ist es wichtig, Speicherschemata so zu gestalten, dass die Beziehung zwischen Post und User auf Basis numerischer IDs erhalten bleibt. Datenkonsument:innen müssen Compliance-Ereignisse sowohl nach Post-ID als auch nach User-ID überwachen und in der Lage sein, den lokalen Datenspeicher entsprechend zu aktualisieren.

• Erstellen Sie Schemata, die alle Compliance-Statuses abdecken: Je nachdem, wie Compliance-Aktivitäten in verschiedenen Anwendungen gehandhabt werden, kann es erforderlich sein, dem Datenspeicher weitere metadata hinzuzufügen. Beispielsweise können Datenkonsument:innen entscheiden, metadata zu einer bestehenden Datenbank hinzuzufügen, um die Anzeige von Inhalten in Ländern einzuschränken, die von einer status_withheld-Nachricht betroffen sind.

• Umgang mit Retweet-Löschungen: Retweets sind eine besondere Art von Post, bei der die ursprüngliche Nachricht in einem Objekt innerhalb des Retweets verschachtelt ist. In diesem Fall werden in einem Retweet zwei Post-IDs referenziert – die ID für den Retweet und die ID für die ursprüngliche Nachricht (im verschachtelten Objekt enthalten). Wenn eine ursprüngliche Nachricht gelöscht wird, wird eine Post delete-Nachricht für die ursprüngliche ID ausgegeben. Post-Löschereignisse lösen typischerweise delete-Ereignisse für alle Retweets aus. In einigen Fällen werden jedoch nicht alle gesendet, und Client-Systeme sollten gegenüber unvollständigen Retweet-Löschungen tolerant sein. Das Löschen der ursprünglichen ID sollte ausreichen, um alle nachfolgenden Retweets zu löschen. Es ist Best Practice, beim Speichern von Retweets auf die ursprüngliche Post-ID zu verweisen und beim Empfang von Post delete-Ereignissen alle referenzierten Retweets zu löschen.

​

Compliance-Datenobjekte

​

Compliance Firehose API

Mögliche Arten von Compliance-Ereignissen umfassen Post-(oder „status“-)Ereignisse sowie Nutzerereignisse; die verschiedenen Typen werden nachfolgend beschrieben.  

Bitte beachten:

• Weitere Informationen zu Nutzer-Status finden Sie hier und unsere Entwicklerrichtlinie zu gelöschten Posts hier.
• Die Compliance Firehose wurde aktualisiert und stellt nun ‘tweet_edit’-Ereignisse bereit. 
• Mehrere Nutzerereignisse wie delete, protect und suspend sind nicht zwingend dauerhaft und können unbegrenzt zwischen Zuständen wechseln. Dazu gehören: user_delete, user_undelete, user_protect, user_unprotect sowie user_suspend und user_unsuspend.
• Auf user_deletes folgen status_deletes 30 Tage später nur, wenn der Nutzer sich nicht für ein user_undelete seines Kontos entschieden hat. Es ist möglich, dass ein user_delete vom Nutzer rückgängig gemacht wird und deshalb 30 Tage später keine Löschungen für alle seine Posts erfolgen.
• user_suspend ist eine Aktion, die bestehen bleibt, sofern für den Nutzer kein user_unsuspend-Ereignis eintritt. Diese unterliegen keinen Änderungen innerhalb eines 30-Tage-Zeitraums.

Siehe die Spalte „Empfohlene Aktion“, um zu verstehen, wie jeder Ereignistyp verarbeitet werden sollte, um die Privatsphäre und Intention des Endnutzers zu respektieren.

Original Message Type	Objekt	Permanent (Ja/Nein)	Empfohlene Aktion
delete	Status	Ja	Zugehörigen Post löschen.
status_withheld	Status	Ja	Zugehörigen Post in den im status_withheld-Message aufgeführten spezifischen Ländern unterdrücken.
drop	Status	Nein	Post aus der öffentlichen Ansicht entfernen.
undrop	Status	Nein	Status kann wieder angezeigt und als öffentlich behandelt werden.
tweet_edit	Status	Ja	Die neue Bearbeitung berücksichtigen und, wo relevant, anzeigen.
user_delete	User	Nein	Alle Posts des zugehörigen Nutzers unterdrücken oder löschen.
user_undelete	User	Nein	Alle Posts des zugehörigen Nutzers können wieder angezeigt und als öffentlich behandelt werden.
user_protect	User	Nein	Alle Posts des zugehörigen Nutzers unterdrücken oder löschen.
user_unprotect	User	Nein	Alle Posts des zugehörigen Nutzers können wieder angezeigt und als öffentlich behandelt werden.
user_suspend	User	Nein	Alle Posts des zugehörigen Nutzers unterdrücken oder löschen.
user_unsuspend	User	Nein	Alle Posts des zugehörigen Nutzers können wieder angezeigt und als öffentlich behandelt werden.
scrub_geo	User	Ja	Alle von X bereitgestellten Geodaten für alle Posts des Nutzers vor dem im scrub_geo-Message angegebenen Post löschen. Beachten Sie, dass nachfolgende Posts eines Nutzers Geodaten enthalten können, die verwendet werden dürfen.
user_withheld	User	Ja	Posts des zugehörigen Nutzers in den im user_withheld-Message aufgeführten spezifischen Ländern unterdrücken.
delete	Favorite	Ja	Zugehöriges like/favorite löschen.

​

Payload-Beispiele

Nachfolgend finden Sie die Payload-Beispiele für jedes in der obigen Tabelle beschriebene Compliance-Ereignis.

Post-Bearbeitung

{"tweet_edit":
   {
     "id": "1557445923210514432"
     "initial_tweet_id": "1557433858676740098",
     "edit_tweet_ids": ["1557433858676740098", "1557445923210514432"],
     "timestamp_ms": "1660155761384"
   }
 }

Post löschen

{
  "delete": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

Post zurückgehalten

{
  "status_withheld": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestamp_ms": "1432228155593"
  }
}

Drop

{
  "drop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

Wiederherstellen gelöschter Elemente

{
  "undrop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

​

Geodaten bereinigen

{
  "scrub_geo": {
    "user_id": 519761961,
    "up_to_status_id": 411552403083628540,
    "up_to_status_id_str": "411552403083628544",
    "user_id_str": "519761961",
    "timestamp_ms": "1432228180345"
  }
}

Benutzer löschen

{
  "user_delete": {
    "id": 771136850,
    "timestamp_ms": "1432228153548"
  }
}

Benutzerkonto-Wiederherstellung

{
  "user_undelete": {
    "id": 796250066,
    "timestamp_ms": "1432228149062"
  }
}

Nutzer zurückgehalten

{
  "user_withheld": {
    "user": {
      "id": 1375036644,
      "id_str": "1375036644"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestampMs": "2014-08-27T23:49:41.839+00:00"
  }
}

Schutz für Benutzer

{
  "user_protect": {
    "id": 3182003550,
    "timestamp_ms": "1432228177137"
  }
}

Schutz für Benutzer aufheben

{
  "user_unprotect": {
    "id": 2911076065,
    "timestamp_ms": "1432228180113"
  }
}

Benutzer sperren

{
  "user_suspend": {
    "id": 3120539094,
    "timestamp_ms": "1432228194217"
  }
}

Nutzer-Reaktivierung

{
  "user_unsuspend": {
    "id": 3293130873,
    "timestamp_ms": "1432228193828"
  }
}

​

Integration der Compliance Firehose

Die Compliance Firehose ist eine Echtzeit-Streaming-API, die Compliance-Ereignisse liefert, die auf der X-Plattform auftreten. Für ein Verständnis von Compliance-Ereignissen und wie sie auf X entstehen, verweisen Sie bitte auf unseren Artikel Honoring User Intent on X.

Es ist wichtig zu beachten, dass Post- und Nutzerereignisse unabhängig voneinander zugestellt werden und jeweils separat verarbeitet werden sollten (d. h. ein Post delete impliziert kein Nutzerereignis und umgekehrt). Mehrere Nutzerereignisse sind nicht unbedingt dauerhaft und können unbegrenzt zwischen Zuständen wechseln. Dazu gehören: user_delete, user_undelete, user_protect, user_unprotect sowie user_suspend, user_unsuspend.

Auf user_deletes folgen status_deletes 30 Tage später nur, wenn der Nutzer nicht gewählt hat, sein Konto mittels user_undelete wiederherzustellen. Es ist möglich, dass ein user_delete vom Nutzer rückgängig gemacht wird und die deletes für alle seine Posts 30 Tage später nicht erfolgen.

User_suspend ist eine Aktion, die bestehen bleibt, es sei denn, der Nutzer unterliegt einem user_unsuspend-Ereignis. Diese unterliegen keinen Änderungen innerhalb eines Zeitraums von 30 Tagen.

Es ist niemals angemessen, Compliance-Ereignisse direkt den Nutzern Ihrer Software anzuzeigen oder sie anderweitig in Ihre Produkte oder Kundenerlebnisse zu integrieren. Sie sind ausschließlich dazu gedacht, Compliance sicherzustellen und die Handlungen von X Nutzern zu respektieren.

​

Integration in die Compliance Firehose

Um die Compliance Firehose in Ihr System zu integrieren, müssen Sie eine Integration erstellen, die Folgendes leistet:

1. Eine Streaming-Verbindung zu jeder Streaming-API-Partition der Compliance Firehose herstellen
2. Hohe Datenvolumina verarbeiten – die Stream-Erfassung mithilfe asynchroner Prozesse von der weiteren Verarbeitung entkoppeln
3. Bei Unterbrechungen aus beliebigen Gründen automatisch die Verbindung zu den Stream-Partitionen wiederherstellen
4. Compliance-Ereignisse verarbeiten, die für die von Ihnen gespeicherten Post- und User-Daten relevant sind, gemäß den oben dargestellten Richtlinien

​

Achtung der Nutzerintention auf Twitter

Wir sind der Überzeugung, dass die Wahrung der Privatsphäre und Intention von X-Nutzern für die langfristige Gesundheit einer der größten öffentlichen Echtzeit-Informationsplattformen der Welt entscheidend ist. X legt die Datenschutzkontrollen in die Hände seiner Nutzer und gibt Einzelpersonen die Möglichkeit, ihre eigene X-Erfahrung zu steuern. Als geschäftliche Nutzer von X data tragen wir eine gemeinsame Verantwortung, die Privatsphäre und Handlungen der Endnutzer zu respektieren, um dieses Klima des Vertrauens und Respekts aufrechtzuerhalten.

Es gibt eine Vielzahl von Vorgängen, die Posts und Nutzerkonten betreffen und beeinflussen, wie sie auf der Plattform angezeigt werden. Die Aktionen, die sich auf Privatsphäre und Intention auswirken, sind sowohl auf Status- (Post) als auch auf Nutzerebene definiert. Diese Aktionen umfassen:

​

Nutzer

Aktion	Beschreibung
Konto schützen	Ein X Nutzer kann sein Konto jederzeit schützen oder den Schutz aufheben. Geschützte Konten erfordern die manuelle Zustimmung des Nutzers für jede Person, die die Posts seines Kontos ansehen darf.  Weitere Informationen finden Sie unter Über öffentliche und geschützte Posts.
Konto löschen	Ein X Nutzer kann jederzeit entscheiden, sein Konto und alle zugehörigen Statusmeldungen zu löschen. X bewahrt die Kontoinformationen 30 Tage nach der Löschung auf, falls der Nutzer sich entscheidet, die Löschung rückgängig zu machen und sein Konto wieder zu aktivieren.
Geo bereinigen	Ein X Nutzer kann jederzeit alle Standortdaten aus früheren Posts entfernen. Dies ist als „scrub geo“ bekannt.
Konto sperren	X behält sich das Recht vor, Konten zu sperren, die gegen die X Regeln verstoßen, oder wenn der Verdacht besteht, dass ein Konto gehackt oder kompromittiert wurde. Kontosperrungen können nur von X rückgängig gemacht (entsperrt) werden.
Konto zurückhalten	X behält sich das Recht vor, von Zeit zu Zeit reaktiv den Zugriff auf bestimmte Inhalte in einem bestimmten Land zurückzuhalten. Ein zurückgehaltenes Konto kann nur von X wieder freigegeben werden.  Weitere Informationen finden Sie unter Inhalte, die in Ländern zurückgehalten werden.

​

Status

Aktion	Beschreibung
Status löschen	Ein X Nutzer kann einen Status jederzeit löschen. Gelöschte Status lassen sich nicht rückgängig machen und werden dauerhaft entfernt.
Status zurückhalten	X behält sich das Recht vor, den Zugriff auf bestimmte Inhalte in einem bestimmten Land von Zeit zu Zeit reaktiv zurückzuhalten. Ein zurückgehaltener Status kann nur von X wieder freigegeben werden.  Weitere Informationen finden Sie unter Country Withheld Content.

​

Nachverfolgung von Änderungen an User und Status

Der Status eines Users oder eines Statusobjekts kann sich jederzeit durch eine der oben genannten Aktionen ändern. Dies wirkt sich darauf aus, wie Verbraucher von X data die Verfügbarkeit und den Schutz aller zugehörigen Inhalte handhaben sollen. Wenn diese Aktionen eintreten, wird eine entsprechende Compliance-Nachricht gesendet, die anzeigt, dass sich der Status eines Statusobjekts oder eines Users geändert hat.

​

API-Referenz

​

GET compliance/firehose

​

Methoden

Methode	Beschreibung
GET /compliance/:stream	Mit dem Datenstream verbinden

​

Authentifizierung

Alle Anfragen an die Compliance Firehose API müssen die HTTP Basic Authentication verwenden, die aus einer gültigen Kombination aus E‑Mail‑Adresse und Passwort besteht, mit der Sie sich bei Ihrem Konto unter console.gnip.com anmelden. Die Anmeldedaten müssen bei jeder Anfrage im Authorization‑Header übermittelt werden.

​

GET /compliance/:stream

Stellt eine persistente Verbindung zum Compliance-Firehose-Stream her, über die Compliance-Ereignisse zugestellt werden.

Request Method	HTTP GET
Connection Type	Keep-Alive
URL	Zu finden auf der API-Hilfeseite des Streams in Ihrem Dashboard und entspricht der folgenden Struktur: https://gnip-stream.x.com/stream/compliance/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1 Hinweis: Der Parameter „partition“ ist erforderlich. Um den vollständigen Stream zu beziehen, müssen Sie eine Verbindung zu allen 8 Partitionen herstellen, die jeweils 12,5 % des Gesamtvolumens enthalten.
Compression	Gzip. Um sich mit Gzip-Komprimierung mit dem Stream zu verbinden, senden Sie in der Verbindungsanfrage einen Accept-Encoding-Header. Der Header sollte wie folgt aussehen: Accept-Encoding: gzip
Character Encoding	UTF-8
Response Format	JSON. Der Header Ihrer Anfrage sollte JSON als Antwortformat angeben.
Rate Limit	10 Anfragen pro 60 Sekunden.
Read Timeout	Setzen Sie auf Ihrem Client ein Read-Timeout und stellen Sie sicher, dass es auf einen Wert von über 30 Sekunden konfiguriert ist.
Support for Tweet edits	Alle Tweet-Edits lösen ein „tweet_edit“-Compliance-Ereignis aus. Weitere Details finden Sie in der Dokumentation zu Compliance Data Objects.

Beispiel-cURL-Anfrage

Die folgende Beispielanfrage wird mit cURL auf der Befehlszeile ausgeführt:

curl --compressed -v [e-mail] "https://gnip-stream.x.com/stream/compliance/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1"

Hinweis: Die oben gezeigte Anfrage stellt nur eine Verbindung zu partition=1 der Compliance-Firehose her – um den gesamten Stream zu empfangen, müssen Sie sich mit allen 8 Partitionen verbinden.

​

Antwortcodes

Die folgenden Antworten kann die API für diese Anfragen zurückgeben. Die meisten Fehlercodes werden zusammen mit einer Zeichenfolge mit zusätzlichen Details im Body zurückgegeben. Bei Antworten ungleich 200 sollten Clients versuchen, die Verbindung erneut herzustellen.

Status	Text	Definition
200	Erfolg	Die Verbindung wurde erfolgreich geöffnet, und neue Aktivitäten werden übermittelt, sobald sie eintreffen.
401	Nicht autorisiert	Die HTTP-Authentifizierung ist aufgrund ungültiger Anmeldedaten fehlgeschlagen. Melden Sie sich mit Ihren Anmeldedaten bei console.gnip.com an, um sicherzustellen, dass Sie sie in Ihrer Anfrage korrekt verwenden.
406	Nicht akzeptabel	Tritt in der Regel auf, wenn Ihr Client die Header zum Akzeptieren von gzip-Codierung aus dem Stream nicht korrekt sendet, kann jedoch auch unter anderen Umständen auftreten. Enthält eine JSON-Nachricht ähnlich „Für diese Verbindung ist Komprimierung erforderlich. Um Komprimierung zu aktivieren, senden Sie einen ‚Accept-Encoding: gzip‘-Header in Ihrer Anfrage und seien Sie bereit, den Stream auf Clientseite zu dekomprimieren, sobald er gelesen wird.“
429	Rate Limited	Ihre App hat das Limit für Verbindungsanfragen überschritten.
503	Dienst nicht verfügbar	Serverproblem bei Twitter. Stellen Sie die Verbindung mithilfe eines exponentiellen Backoff-Musters wieder her. Wenn auf der X API Status Page keine Mitteilung zu diesem Problem veröffentlicht wurde, kontaktieren Sie den Support.

​

Weitere Empfehlungen und Best Practices

• Entwerfen Sie Datenspeicher-Schemata, die numerische Tweet-id und User-id speichern: User-bezogene Nachrichten erfordern Maßnahmen für alle Tweets dieses Users. Da alle Compliance-Nachrichten ausschließlich über numerische ids zugestellt werden, ist es wichtig, Speicherschemata so zu gestalten, dass die Beziehung zwischen Tweet und User auf Basis numerischer ids erhalten bleibt. Datenkonsument:innen müssen Compliance-Ereignisse sowohl nach Tweet-id als auch nach User-id überwachen und in der Lage sein, den lokalen Datenspeicher entsprechend zu aktualisieren.

• Erstellen Sie Schemata, die alle Compliance-Statuses abdecken: Je nachdem, wie Compliance-Aktivitäten in verschiedenen Anwendungen gehandhabt werden, kann es erforderlich sein, dem Datenspeicher weitere metadata hinzuzufügen. Beispielsweise können sich Datenkonsument:innen entscheiden, metadata zu einer bestehenden Datenbank hinzuzufügen, um die Anzeige von Inhalten in Ländern zu beschränken, die von einer status_withheld-Nachricht betroffen sind.

• Umgang mit Retweet-Löschungen: Retweets sind eine besondere Art von Tweet, bei der die Originalnachricht in einem Objekt innerhalb des Retweets verschachtelt ist. In diesem Fall werden in einem Retweet zwei Tweet-ids referenziert – die id für den Retweet und die id für die Originalnachricht (enthalten im verschachtelten Objekt). Wenn eine Originalnachricht gelöscht wird, wird eine Tweet delete-Nachricht für die ursprüngliche id ausgegeben. Nachfolgende delete-Nachrichten werden NICHT für alle Retweets ausgegeben. Das Löschen der ursprünglichen id sollte ausreichen, um alle nachfolgenden Retweets zu entfernen.