> ## Documentation Index
> Fetch the complete documentation index at: https://generaltranslation.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# API Compliance Firehose
> **Veuillez noter**
>
> Nous avons lancé un nouvel outil de conformité pour X API v2 appelé [batch compliance](/fr/x-api/compliance/batch-compliance). Ce nouvel outil vous permet de téléverser de grands ensembles de données contenant des ID de Publication ou d’utilisateur afin de récupérer leur statut de conformité et de déterminer quelles données nécessitent une action pour rendre vos ensembles de données conformes.
> De plus, batch compliance et compliance firehose ont été mis à jour pour prendre en charge les modifications de Publications. Pour compliance firehose, un nouvel événement « tweet\_edit » a été ajouté. Consultez la documentation [Compliance Data Objects](/fr/x-api/enterprise-gnip-2.0/fundamentals/firehouse#compliance-data-objects) pour plus de détails. Pour en savoir plus sur le fonctionnement des métadonnées de modification de Publication, consultez la page [Edit Posts fundamentals](/fr/x-api/fundamentals/edit-posts).
## Aperçu
`Enterprise`
L’une des valeurs fondamentales de X est de défendre et de respecter la voix de l’utilisateur. Cela inclut le respect de ses attentes et de son intention lorsqu’il supprime, modifie ou édite le contenu qu’il choisit de partager sur X. Nous pensons que cela est d’une importance cruciale pour la santé à long terme de l’une des plus grandes plateformes publiques d’information en temps réel au monde. X met des contrôles entre les mains de ses utilisateurs, en donnant à chacun la possibilité de contrôler sa propre expérience sur X. Nous considérons que les clients professionnels qui reçoivent des données X ont la responsabilité de respecter les attentes et l’intention des utilisateurs finaux.
Pour plus d’informations sur les types d’événements de conformité possibles sur la plateforme X, consultez notre article : [Honoring User Intent on X](/fr/x-api/enterprise-gnip-2.0/fundamentals/firehouse#honoring-user-intent-on-twitter).
Tout développeur ou entreprise qui utilise des données X via une API a l’obligation de déployer tous les efforts raisonnables pour respecter les modifications apportées au contenu des utilisateurs. Cette obligation s’étend aux événements liés aux utilisateurs, tels que les suppressions, les modifications et les changements d’options de partage (par exemple, lorsque le contenu devient protégé, retiré ou restreint). Cela inclut également les cas où les utilisateurs modifient leurs Publications. Veuillez vous référer au libellé spécifique de la [Developer Policy](https://developer.x.com/en/developer-terms/policy) et/ou de votre Contrat de données X pour comprendre comment cette obligation affecte votre utilisation des données X.
X propose les solutions suivantes, qui fournissent des informations sur ces événements de conformité liés aux utilisateurs et indiquent si une Publication ou un utilisateur spécifique est publiquement accessible ou non. Un bref aperçu de ces solutions et de leurs modèles d’intégration généraux est présenté ci‑dessous :
#### GET statuses/lookup et GET users/lookup
* Format : API REST. Voir [GET statuses/lookup](https://developer.x.com/en/docs/x-api/v1/tweets/post-and-engage/api-reference/get-statuses-lookup) et [GET users/lookup](https://developer.x.com/en/docs/x-api/v1/accounts-and-users/follow-search-get-users/api-reference/get-users-lookup).
* Ces endpoints renvoient toujours la dernière version d’une Publication, en tenant compte de toutes les modifications éventuelles. Tous les objets Publication décrivant des Publications créées après l’introduction de la fonctionnalité d’édition incluront les métadonnées d’édition de la Publication. Cela est vrai même pour les Publications qui n’ont pas été modifiées.
* Pour toutes les Publications, les requêtes effectuées plus de 30 minutes après leur création renverront l’état final de ces Publications.
* Fournissent des informations de disponibilité pour des Publications ou des utilisateurs spécifiques, tels que définis par l’appelant dans la requête API.
* Peuvent être utilisés pour des vérifications ponctuelles ad hoc de l’état de disponibilité actuel d’un groupe spécifique de Publications ou d’utilisateurs.
* Idéaux pour les clients qui ont besoin d’un moyen de vérifier l’état actuel d’une Publication ou d’un utilisateur donné à un moment précis.
* Ces API fournissent un mécanisme utile qui peut être utilisé par les clients qui doivent vérifier la disponibilité d’un élément de contenu, par exemple lorsque :
1. Afficher des Publications
2. Interagir avec une ou plusieurs Publications ou avec des utilisateurs de manière individuelle (1:1)
3. Distribuer du contenu X à un tiers via un téléchargement de fichier autorisé
4. Conserver des Publications pendant de longues périodes
#### Compliance Firehose (offre Enterprise uniquement)
* Format : API de streaming. Voir : [Compliance Firehose](/fr/x-api/enterprise-gnip-2.0/fundamentals/firehouse#api-reference).
* Fournit un flux en temps réel des [activités de conformité](/fr/x-api/enterprise-gnip-2.0/fundamentals/firehouse#compliance-data-objects) sur X. Ces activités incluent la modification de Publications.
* Peut être utilisé pour maintenir l’état de conformité au sein d’un ensemble de données stockées à mesure que de nouveaux événements de conformité se produisent sur la plateforme.
* Idéal pour les clients qui consomment et stockent de grandes quantités de données issues de X pendant de longues périodes.
## Guides
### **Bonnes pratiques en matière de conformité**
#### **Recommandations et meilleures pratiques**
* **Concevoir des schémas de stockage de données qui conservent l’ID numérique de Publication et l’ID d’utilisateur** : les messages des utilisateurs nécessitent une action à effectuer sur toutes les Publications de cet utilisateur. Par conséquent, comme tous les messages de conformité sont fournis uniquement par ID numérique, il est important de concevoir des schémas de stockage qui maintiennent la relation entre la Publication et l’utilisateur sur la base des IDs numériques. Les consommateurs de données devront surveiller les événements de conformité à la fois par ID de Publication et par ID d’utilisateur, et être en mesure de mettre à jour le magasin de données local de manière appropriée.
* **Concevoir des schémas qui prennent en charge tous les statuts de conformité** : selon la façon dont les activités de conformité seront prises en compte dans les différentes applications, il peut être nécessaire d’ajouter d’autres métadonnées au magasin de données. Par exemple, les consommateurs de données peuvent décider d’ajouter des métadonnées à une base de données existante pour faciliter la restriction de l’affichage de contenu dans les pays concernés par un message `status_withheld`.
* **Gérer les suppressions de Retweet** : les Retweets sont un type particulier de Publication où le message original est imbriqué dans un objet à l’intérieur du Retweet. Dans ce cas, deux IDs de Publication sont référencés dans un Retweet : l’ID du Retweet et l’ID du message original (inclus dans l’objet imbriqué). Lorsqu’un message original est supprimé, un message de suppression de Publication est émis pour l’ID original. Les événements de suppression de Publication déclenchent généralement des événements de suppression pour tous les Retweets. Cependant, dans certains cas, ils ne sont pas tous envoyés et les systèmes clients doivent être tolérants aux suppressions de Retweet incomplètes. La suppression de l’ID original devrait suffire à supprimer tous les Retweets ultérieurs. Il s’agit d’une bonne pratique de référencer l’ID de Publication original lors du stockage des Retweets, et de supprimer tous les Retweets référencés lors de la réception d’événements de suppression de Publication.
### Objets de données de conformité
#### **Compliance Firehose API**
Les types possibles d’événements de conformité incluront des événements de Publication (ou « status ») et des événements d’Utilisateur, pour lesquels plusieurs types sont décrits ci‑dessous.
Veuillez noter :
* Pour en savoir plus sur les statuts d’Utilisateur, consultez [cet article](https://support.x.com/articles/14016) et prenez connaissance de notre politique développeur concernant les Publications supprimées [ici](https://dev.x.com/overview/terms/policy#3.Update_Respect_Users_Control_and_Privacy).
* L’API Compliance Firehose a été mise à jour pour fournir des événements `tweet_edit`.
* Plusieurs événements de suppression, protection et suspension d’Utilisateur ne sont pas nécessairement permanents et peuvent basculer indéfiniment entre différents états. Ceux‑ci incluent : user\_delete, user\_undelete, user\_protect, user\_unprotect et user\_suspend, user\_unsuspend.
* Les user\_deletes sont suivis de status\_deletes 30 jours plus tard uniquement si l’utilisateur n’a pas choisi d’effectuer un user\_undelete de son compte. Il est possible qu’un user\_delete soit annulé par l’utilisateur et que les suppressions de toutes ses Publications 30 jours plus tard ne se produisent pas.
* user\_suspend est une action qui reste vraie, sauf si l’utilisateur fait l’objet d’un événement user\_unsuspend. Ceux‑ci ne sont soumis à aucune modification au terme d’une période de 30 jours.
Reportez‑vous à la colonne « Action recommandée » pour comprendre comment traiter chaque type d’événement afin de respecter la confidentialité et l’intention de l’utilisateur final.
| Original Message Type | Object | Permanent (Yes/No) | Recommended Action |
| :-------------------- | :------- | :----------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| delete | Status | Yes | Supprimer la Publication associée. |
| status\_withheld | Status | Yes | Masquer la Publication associée dans les pays spécifiques listés dans le message status\_withheld. |
| drop | Status | No | Retirer la Publication de l’affichage public. |
| undrop | Status | No | La Publication peut de nouveau être affichée et traitée comme publique. |
| tweet\_edit | Status | Yes | Respecter et, le cas échéant, afficher la nouvelle modification. |
| user\_delete | User | No | Masquer ou supprimer toutes les Publications de l’utilisateur associé. |
| user\_undelete | User | No | Toutes les Publications de l’utilisateur associé peuvent de nouveau être affichées et traitées comme publiques. |
| user\_protect | User | No | Masquer ou supprimer toutes les Publications de l’utilisateur associé. |
| user\_unprotect | User | No | Toutes les Publications de l’utilisateur associé peuvent de nouveau être affichées et traitées comme publiques. |
| user\_suspend | User | No | Masquer ou supprimer toutes les Publications de l’utilisateur associé. |
| user\_unsuspend | User | No | Toutes les Publications de l’utilisateur associé peuvent de nouveau être affichées et traitées comme publiques. |
| scrub\_geo | User | Yes | Supprimer toutes les géodonnées fournies par X pour toutes les Publications de l’utilisateur antérieures à la Publication spécifiée dans le message scrub\_geo. Notez que les Publications ultérieures d’un utilisateur peuvent contenir des géodonnées qui peuvent être utilisées. |
| user\_withheld | User | Yes | Masquer les Publications de l’utilisateur associé dans les pays spécifiques listés dans le message user\_withheld. |
| delete | Favorite | Yes | Supprimer le like/favori associé. |
#### **Exemples de payloads**
Vous trouverez ci-dessous des exemples de payload pour chaque événement de conformité présenté dans le tableau ci-dessus.
**Modification de publication**
```json theme={null}
{"tweet_edit":
{
"id": "1557445923210514432"
"initial_tweet_id": "1557433858676740098",
"edit_tweet_ids": ["1557433858676740098", "1557445923210514432"],
"timestamp_ms": "1660155761384"
}
}
```
##### Suppression de publication
```json theme={null}
{
"delete": {
"status": {
"id": 601430178305220600,
"id_str": "601430178305220608",
"user_id": 3198576760,
"user_id_str": "3198576760"
},
"timestamp_ms": "1432228155593"
}
}
```
##### Publication bloquée
```json theme={null}
{
"status_withheld": {
"status": {
"id": 601430178305220600,
"id_str": "601430178305220608",
"user_id": 3198576760,
"user_id_str": "3198576760"
},
"withheld_in_countries": [
"XY"
],
"timestamp_ms": "1432228155593"
}
}
```
##### Suppression
```json theme={null}
{
"drop": {
"status": {
"id": 601430178305220600,
"id_str": "601430178305220600",
"user_id": 3198576760,
"user_id_str": "3198576760"
},
"timestamp_ms": "1432228155593"
}
}
```
##### Restaurer
```json theme={null}
{
"undrop": {
"status": {
"id": 601430178305220600,
"id_str": "601430178305220600",
"user_id": 3198576760,
"user_id_str": "3198576760"
},
"timestamp_ms": "1432228155593"
}
}
```
#### Nettoyage des données de géolocalisation
```json theme={null}
{
"scrub_geo": {
"user_id": 519761961,
"up_to_status_id": 411552403083628540,
"up_to_status_id_str": "411552403083628544",
"user_id_str": "519761961",
"timestamp_ms": "1432228180345"
}
}
```
##### Suppression d’un utilisateur
```json theme={null}
{
"user_delete": {
"id": 771136850,
"timestamp_ms": "1432228153548"
}
}
```
##### Annulation de la suppression de l’utilisateur
```json theme={null}
{
"user_undelete": {
"id": 796250066,
"timestamp_ms": "1432228149062"
}
}
```
##### Utilisateur masqué
```json theme={null}
{
"user_withheld": {
"user": {
"id": 1375036644,
"id_str": "1375036644"
},
"withheld_in_countries": [
"XY"
],
"timestampMs": "2014-08-27T23:49:41.839+00:00"
}
}
```
##### Protéger l’utilisateur
```json theme={null}
{
"user_protect": {
"id": 3182003550,
"timestamp_ms": "1432228177137"
}
}
```
##### Annulation de la protection du compte
```json theme={null}
{
"user_unprotect": {
"id": 2911076065,
"timestamp_ms": "1432228180113"
}
}
```
##### Suspension d’un utilisateur
```json theme={null}
{
"user_suspend": {
"id": 3120539094,
"timestamp_ms": "1432228194217"
}
}
```
##### Réactivation d’un compte utilisateur
```json theme={null}
{
"user_unsuspend": {
"id": 3293130873,
"timestamp_ms": "1432228193828"
}
}
```
### intégration de Compliance Firehose
La Compliance Firehose est une API de streaming en temps réel qui diffuse les événements de conformité se produisant sur la plateforme X. Pour comprendre les événements de conformité et la façon dont ils sont générés sur X, veuillez consulter notre article : [Honorer l’intention des utilisateurs sur X](/fr/x-api/enterprise-gnip-2.0/fundamentals/firehouse#honoring-user-intent-on-twitter).
Il est important de noter que les événements Publication et User sont diffusés indépendamment et que chacun doit être traité indépendamment (c’est-à-dire qu’une suppression de Publication n’implique pas un événement User, et inversement). Plusieurs événements User ne sont pas nécessairement permanents et peuvent basculer entre différents états indéfiniment. Ceux-ci incluent : user\_delete, user\_undelete, user\_protect, user\_unprotect et user\_suspend, user\_unsuspend.
Les user\_delete sont suivis d’événements status\_delete 30 jours plus tard uniquement si l’utilisateur n’a pas choisi de procéder à un user\_undelete de son compte. Il est possible qu’un user\_delete soit annulé par l’utilisateur et que les suppressions de toutes ses Publications 30 jours plus tard ne se produisent pas.
user\_suspend est une action qui reste en vigueur, sauf si l’utilisateur fait l’objet d’un événement user\_unsuspend. Ceux-ci ne sont soumis à aucune modification sur une période de 30 jours.
Il n’est jamais approprié d’afficher directement les événements de conformité aux utilisateurs de votre logiciel ni de les intégrer d’une quelconque manière dans vos produits ou expériences client. Ils sont exclusivement destinés à maintenir la conformité et à respecter les actions des utilisateurs de X.
#### **Intégrer le Compliance Firehose**
Pour intégrer le Compliance Firehose à votre système, vous devez créer une intégration capable d’effectuer les opérations suivantes :
1. Établir une connexion de streaming à chaque partition d’API de streaming du Compliance Firehose
2. Gérer des volumes de données élevés – découpler l’ingestion du flux du traitement supplémentaire au moyen de processus asynchrones
3. Rétablir automatiquement la connexion aux partitions de flux lorsqu’une déconnexion se produit pour quelque raison que ce soit
4. Traiter les événements de conformité pertinents pour les données de Publication et d’Utilisateur que vous avez stockées, conformément aux recommandations présentées ci-dessus
Nous estimons que le respect de la vie privée et de l’intention des utilisateurs de X est essentiel pour la santé à long terme de l’une des plus grandes plateformes publiques d’information en temps réel au monde. X met les contrôles de confidentialité entre les mains de ses utilisateurs, en leur donnant la possibilité de contrôler leur propre expérience sur X. En tant qu’acteurs commerciaux exploitant les données de X, nous avons la responsabilité collective de respecter la confidentialité et les actions des utilisateurs finaux afin de maintenir cet environnement de confiance et de respect.
Un certain nombre de choses peuvent arriver aux Publications et aux comptes utilisateur, ce qui influe sur la façon dont ils sont affichés sur la plateforme. Les actions qui affectent la confidentialité et l’intention sont définies à la fois au niveau du statut (Publication) et au niveau utilisateur. Ces actions comprennent :
#### Utilisateur
| Action | Description |
| :-------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Protéger le compte | Un utilisateur X peut protéger ou retirer la protection de son compte à tout moment. Les comptes protégés nécessitent l’approbation manuelle, par l’utilisateur, de chaque personne autorisée à voir les Publications de son compte.
Pour en savoir plus, consultez [À propos des Publications publiques et protégées](https://support.x.com/articles/14016-about-public-and-protected-tweets). |
| Supprimer le compte | Un utilisateur X peut décider de supprimer son compte et tous les messages de statut associés à tout moment. X conserve les informations du compte pendant 30 jours après la suppression au cas où l’utilisateur déciderait de revenir sur cette suppression et de réactiver son compte. |
| Nettoyer les données de géolocalisation | Un utilisateur X peut supprimer toutes les données de localisation de ses anciennes Publications à tout moment. Ceci est appelé « scrub geo ». |
| Suspendre le compte | X se réserve le droit de suspendre les comptes qui enfreignent les Règles de X ou lorsqu’il est soupçonné qu’un compte a été piraté ou compromis. Les suspensions de compte ne peuvent être levées (réactivation) que par X. |
| Mettre le compte en retenue | X se réserve le droit de restreindre, de manière réactive, l’accès à certains contenus dans un pays spécifique, de temps à autre. Un compte en retenue ne peut être rétabli (retiré de la retenue) que par X.
Pour en savoir plus, consultez [Contenu retenu par pays](https://support.x.com/articles/20169222-country-withheld-content). |
#### Statut
| Action | Description |
| :------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Supprimer le statut | Un utilisateur de X peut supprimer un statut à tout moment. Les statuts supprimés ne peuvent pas être restaurés et sont définitivement supprimés. |
| Retenir le statut | X se réserve le droit de restreindre de manière réactive l’accès à certains contenus dans un pays donné, et ce ponctuellement. Un statut restreint ne peut être rendu à nouveau accessible que par X.
Pour plus d’informations, consultez [Contenu restreint par pays](https://support.x.com/articles/20169222-country-withheld-content). |
#### Suivi des changements d’état de User et de Status
L’état d’un User ou d’un Status peut changer à tout moment en raison de l’une des actions ci-dessus, ce qui influe sur la manière dont les consommateurs de données X doivent traiter la disponibilité et la confidentialité de l’ensemble du contenu associé. Lorsque ces actions se produisent, un message de conformité correspondant est envoyé pour indiquer que l’état d’un Status ou d’un User a changé.
## Référence de l’API
### **GET compliance/firehose**
#### Méthodes
| Méthode | Description |
| :---------------------------------- | :------------------------------ |
| [GET /compliance/:stream](#Connect) | Se connecter au flux de données |
#### Authentification
Toutes les requêtes vers l'API Compliance Firehose doivent utiliser l'authentification HTTP Basic, basée sur une combinaison valide d'adresse e-mail et de mot de passe que vous utilisez pour vous connecter à votre compte sur console.gnip.com. Les identifiants doivent être transmis dans l'en-tête Authorization pour chaque requête.
#### GET /compliance/:stream
Établit une connexion persistante au flux de données Compliance Firehose, par lequel les événements de conformité seront transmis.
| | |
| :-------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Request Method** | HTTP GET |
| **Connection Type** | Keep-Alive |
| **URL** | Indiquée sur la page d'aide API du flux dans votre tableau de bord et ressemble à la structure suivante :
[https://gnip-stream.x.com/stream/compliance/accounts/:account\_name/publishers/twitter/:stream\_label.json?partition=1](https://gnip-stream.x.com/stream/compliance/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1)
**Remarque :** le paramètre "partition" est requis. Vous devrez vous connecter aux 8 partitions, chacune contenant 12,5 % du volume total, pour consommer l'intégralité du flux. |
| **Compression** | Gzip. Pour vous connecter au flux à l'aide de la compression Gzip, envoyez simplement un en-tête Accept-Encoding dans la requête de connexion. L'en-tête doit ressembler à ce qui suit :
Accept-Encoding: gzip |
| **Character Encoding** | UTF-8 |
| **Response Format** | JSON. L'en-tête de votre requête doit spécifier le format JSON pour la réponse. |
| **Rate Limit** | 10 requêtes par 60 secondes. |
| **Read Timeout** | Configurez un délai d'expiration de lecture dans votre client et assurez-vous qu'il est défini sur une valeur supérieure à 30 secondes. |
| **Support for Tweet edits** | Toute modification d'un Tweet déclenche un événement de conformité "tweet\_edit". Consultez la documentation [Compliance Data Objects](/fr/x-api/enterprise-gnip-2.0/fundamentals/firehouse#compliance-data-objects) pour plus de détails. |
**Example Curl Request**
L'exemple de requête suivant est réalisé à l'aide de cURL en ligne de commande :
```bash theme={null}
curl --compressed -v -uexample@customer.com "https://gnip-stream.x.com/stream/compliance/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1"
```
*Remarque :* la requête ci-dessus ne se connecte qu'à `partition=1` du Compliance firehose ; vous devrez vous connecter aux 8 partitions pour consommer l’ensemble de ce flux.
#### Codes de réponse
Les réponses suivantes peuvent être renvoyées par l’API pour ces requêtes. La plupart des codes d’erreur sont renvoyés avec une chaîne de caractères contenant des détails supplémentaires dans le corps de la réponse. Pour les réponses dont le code est différent de 200, les clients doivent tenter de se reconnecter.
| Status | Text | Definition |
| :----- | :------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 200 | Success | La connexion a été ouverte avec succès et les nouvelles activités seront envoyées au fur et à mesure de leur arrivée. |
| 401 | Unauthorized | L’authentification HTTP a échoué en raison d’identifiants non valides. Connectez-vous à console.gnip.com avec vos identifiants pour vous assurer que vous les utilisez correctement avec votre requête. |
| 406 | Not Acceptable | En général, cela se produit lorsque votre client n’inclut pas correctement les en-têtes pour accepter l’encodage gzip du flux, mais cela peut également se produire dans d’autres circonstances. Contiendra un message JSON similaire à : "This connection requires compression. To enable compression, send an 'Accept-Encoding: gzip' header in your request and be ready to uncompress the stream as it is read on the client end." |
| 429 | Rate Limited | Votre application a dépassé la limite des requêtes de connexion. |
| 503 | Service Unavailable | Problème de serveur Twitter. Reconnectez-vous en utilisant une stratégie de reprise avec temporisation exponentielle. Si aucun avis concernant ce problème n’a été publié sur la [X API Status Page](https://api.twitterstat.us/), contactez l’assistance. |
#### Autres recommandations et bonnes pratiques
* **Concevoir des schémas de stockage de données qui conservent l’ID numérique du Tweet et l’ID numérique de l’utilisateur** : les messages relatifs aux utilisateurs exigent qu’une action soit effectuée sur tous les Tweets de cet utilisateur. Par conséquent, étant donné que tous les messages de conformité sont fournis uniquement via des ID numériques, il est important de concevoir des schémas de stockage qui maintiennent la relation entre le Tweet et l’utilisateur à partir de ces ID numériques. Les consommateurs de données devront surveiller les événements de conformité à la fois par ID de Tweet et par ID d’utilisateur, et être en mesure de mettre à jour le stockage de données local en conséquence.
* **Concevoir des schémas qui prennent en compte tous les statuts de conformité** : selon la manière dont les activités de conformité seront gérées dans les différentes applications, il peut être nécessaire d’ajouter d’autres métadonnées au stockage de données. Par exemple, les consommateurs de données peuvent décider d’ajouter des métadonnées à une base de données existante pour faciliter la restriction de l’affichage de contenu dans les pays concernés par un message `status_withheld`.
* **Gestion des suppressions de Retweets** : les Retweets sont un type particulier de Tweet où le message original est imbriqué dans un objet au sein du Retweet. Dans ce cas, deux ID de Tweet sont référencés dans un Retweet : l’ID du Retweet et l’ID du message original (inclus dans l’objet imbriqué). Lorsqu’un message original est supprimé, un message de suppression de Tweet est émis pour l’ID original. Des messages de suppression ultérieurs NE sont PAS émis pour tous les Retweets. La suppression de l’ID original doit suffire à supprimer tous les Retweets ultérieurs.