Passer au contenu principal
Veuillez noter Nous avons lancé un nouvel outil de conformité pour X API v2 appelé 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 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.

​
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. 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 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 et 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.
  • Fournit un flux en temps réel des activités de conformité 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 et prenez connaissance de notre politique développeur concernant les Publications supprimées ici.
  • 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 TypeObjectPermanent (Yes/No)Recommended Action
deleteStatusYesSupprimer la Publication associée.
status_withheldStatusYesMasquer la Publication associée dans les pays spécifiques listés dans le message status_withheld.
dropStatusNoRetirer la Publication de l’affichage public.
undropStatusNoLa Publication peut de nouveau être affichée et traitée comme publique.
tweet_editStatusYesRespecter et, le cas échéant, afficher la nouvelle modification.
user_deleteUserNoMasquer ou supprimer toutes les Publications de l’utilisateur associé.
user_undeleteUserNoToutes les Publications de l’utilisateur associé peuvent de nouveau être affichées et traitées comme publiques.
user_protectUserNoMasquer ou supprimer toutes les Publications de l’utilisateur associé.
user_unprotectUserNoToutes les Publications de l’utilisateur associé peuvent de nouveau être affichées et traitées comme publiques.
user_suspendUserNoMasquer ou supprimer toutes les Publications de l’utilisateur associé.
user_unsuspendUserNoToutes les Publications de l’utilisateur associé peuvent de nouveau être affichées et traitées comme publiques.
scrub_geoUserYesSupprimer 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_withheldUserYesMasquer les Publications de l’utilisateur associé dans les pays spécifiques listés dans le message user_withheld.
deleteFavoriteYesSupprimer 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 
{"tweet_edit":
   {
     "id": "1557445923210514432"
     "initial_tweet_id": "1557433858676740098",
     "edit_tweet_ids": ["1557433858676740098", "1557445923210514432"],
     "timestamp_ms": "1660155761384"
   }
 }
Suppression de publication
{
  "delete": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}
Publication bloquée
{
  "status_withheld": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestamp_ms": "1432228155593"
  }
}
Suppression
{
  "drop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}
Restaurer
{
  "undrop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

​
Nettoyage des données de géolocalisation

{
  "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
{
  "user_delete": {
    "id": 771136850,
    "timestamp_ms": "1432228153548"
  }
}
Annulation de la suppression de l’utilisateur
{
  "user_undelete": {
    "id": 796250066,
    "timestamp_ms": "1432228149062"
  }
}
Utilisateur masqué
{
  "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
{
  "user_protect": {
    "id": 3182003550,
    "timestamp_ms": "1432228177137"
  }
}
Annulation de la protection du compte
{
  "user_unprotect": {
    "id": 2911076065,
    "timestamp_ms": "1432228180113"
  }
}
Suspension d’un utilisateur
{
  "user_suspend": {
    "id": 3120539094,
    "timestamp_ms": "1432228194217"
  }
}
Réactivation d’un compte utilisateur
{
  "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. 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

​
Respecter l’intention des utilisateurs sur Twitter

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

ActionDescription
Protéger le compteUn 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.
Supprimer le compteUn 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éolocalisationUn utilisateur X peut supprimer toutes les données de localisation de ses anciennes Publications à tout moment. Ceci est appelé « scrub geo ».
Suspendre le compteX 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 retenueX 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.

​
Statut

ActionDescription
Supprimer le statutUn 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 statutX 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.

​
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éthodeDescription
GET /compliance/:streamSe 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 MethodHTTP GET
Connection TypeKeep-Alive
URLIndiqué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

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.
CompressionGzip. 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 EncodingUTF-8
Response FormatJSON. L’en-tête de votre requête doit spécifier le format JSON pour la réponse.
Rate Limit10 requêtes par 60 secondes.
Read TimeoutConfigurez 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 editsToute modification d’un Tweet déclenche un événement de conformité “tweet_edit”. Consultez la documentation 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 : 
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.
StatusTextDefinition
200SuccessLa connexion a été ouverte avec succès et les nouvelles activités seront envoyées au fur et à mesure de leur arrivée.
401UnauthorizedL’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.
406Not AcceptableEn 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.”
429Rate LimitedVotre application a dépassé la limite des requêtes de connexion.
503Service UnavailableProblè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, 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.