Passer au contenu principal
Veuillez noter Nous avons lancé un nouvel outil de conformité pour la X API v2, appelé batch compliance. Cet outil vous permet de téléverser de grands ensembles d’ids de Post ou d’utilisateurs afin d’obtenir leur statut de conformité et de déterminer quelles données nécessitent une action pour mettre vos ensembles de données en conformité.
De plus, batch compliance et le firehose de conformité ont été mis à jour pour prendre en charge les modifications de Post. Pour le firehose de conformité, 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 metadata d’édition de Post, 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 des utilisateurs. Cela inclut le respect de leurs attentes et de leur intention lorsqu’ils suppriment, modifient ou corrigent le contenu qu’ils choisissent de partager sur X. Nous estimons que cela est crucial pour la santé à long terme de l’une des plus grandes plateformes publiques d’information en temps réel au monde. X remet les contrôles entre les mains de ses utilisateurs, leur donnant la capacité de maîtriser leur propre expérience sur X. Nous considérons que les entreprises qui reçoivent des données X ont la responsabilité d’honorer 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 toute entreprise consommant 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 utilisateur tels que les suppressions, modifications et changements d’options de partage (par exemple, lorsque du contenu devient protégé ou restreint). Elle couvre également les cas où les utilisateurs modifient leurs Posts. Veuillez vous référer au libellé spécifique de la Developer Policy et/ou de votre X Data Agreement 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é utilisateur et indiquent si un Post ou un utilisateur donné est publiquement accessible ou non. Un bref aperçu des 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 de toute édition d’un Post. Tous les Objets Post décrivant des Posts créés après l’introduction de la fonctionnalité d’édition incluront les metadata d’édition de Post. Cela vaut même pour les Posts qui n’ont pas été édités.
  • Pour tous les Posts, les requêtes effectuées plus de 30 minutes après leur création refléteront l’état final des Posts.
  • Fournissent des informations de disponibilité pour des Posts 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 Posts/utilisateurs.
  • Idéal pour les clients qui ont besoin de vérifier l’état actuel d’un Post ou d’un utilisateur à un moment donné.
  • Ces API fournissent un mécanisme utile qui peut être utilisé par les clients qui doivent vérifier la disponibilité d’un contenu, par exemple lorsque :
    1. Afficher des Posts
    2. Interagir de manière 1:1 avec un ou des Post(s) ou utilisateur(s)
    3. Distribuer du contenu X à un tiers via un téléchargement de fichier autorisé
    4. Stocker des Posts pendant de longues périodes

​
Compliance Firehose (Enterprise uniquement)

  • Format : API de streaming. Voir : Compliance Firehose.
  • Fournit un stream en temps réel des activités de conformité sur X. Ces activités incluent l’édition de Posts.
  • Peut être utilisé pour maintenir l’état de conformité d’un ensemble de data stockées à mesure que de nouveaux événements de conformité surviennent sur la plateforme.
  • Idéal pour les clients qui ingèrent et stockent de grandes quantités de data X sur de longues périodes.

​
Guides

​
Meilleures pratiques en matière de conformité

​
Recommandations et bonnes pratiques

  • Concevoir des schémas de stockage de données qui conservent l’ID de Post numérique et l’ID d’utilisateur : Les messages de conformité exigent d’agir sur tous les Posts de l’utilisateur concerné. Par conséquent, puisque tous les messages de conformité ne sont fournis que par ID numérique, il est important de concevoir des schémas de stockage qui maintiennent la relation entre le Post et l’utilisateur sur la base d’ID numériques. Les consommateurs de données devront surveiller les événements de conformité à la fois par ID de Post et par ID d’utilisateur et être en mesure de mettre à jour correctement le magasin de données local.
  • Concevoir des schémas qui couvrent tous les statuts de conformité : Selon la manière dont les activités de conformité seront prises en charge dans diverses applications, il peut être nécessaire d’ajouter d’autres metadata au magasin de données. Par exemple, les consommateurs de données peuvent décider d’ajouter des metadata à une base de données existante afin de 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 Post où le message d’origine est imbriqué dans un objet au sein du Retweet. Dans ce cas, deux ID de Post sont référencés dans un Retweet : l’ID du Retweet et l’ID du message d’origine (inclus dans l’objet imbriqué). Lorsqu’un message d’origine est supprimé, un message de suppression de Post est émis pour l’ID d’origine. Les événements de suppression de Post 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 tolérer des suppressions de Retweet incomplètes. La suppression de l’ID d’origine devrait suffire à supprimer tous les Retweets ultérieurs. Il est recommandé, comme bonne pratique, de référencer l’ID de Post d’origine 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 Post.

​
Objets de données de conformité

​
API Firehose de conformité

Les types possibles d’événements de conformité incluent des événements de Post (ou « status ») et des événements d’utilisateur, pour lesquels plusieurs types sont décrits ci-dessous.   Veuillez noter :
  • En savoir plus sur les statuts d’utilisateur ici et notre politique développeur concernant les Posts supprimés ici.
  • Le Firehose de conformité a été mis à jour pour fournir des événements « tweet_edit ».
  • Plusieurs événements de suppression, de protection et de suspension d’utilisateur ne sont pas nécessairement permanents et peuvent alterner entre des états indéfiniment. Ils incluent : user_delete, user_undelete, user_protect, user_unprotect, user_suspend et user_unsuspend.
  • Les user_delete sont suivis de status_delete 30 jours plus tard uniquement si l’utilisateur n’a pas choisi de user_undelete son compte. Il est possible qu’un user_delete soit annulé par l’utilisateur et que les suppressions de tous ses Posts 30 jours plus tard n’aient pas lieu.
  • user_suspend est une action qui reste effective sauf si l’utilisateur est soumis à un événement user_unsuspend. Ces événements ne sont soumis à aucun changement sur une période de 30 jours.
Reportez-vous à la colonne « Recommended Action » 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 le Post associé.
status_withheldStatusYesMasquer le Post associé dans les pays spécifiques listés dans le message status_withheld.
dropStatusNoRetirer le Post de la vue publique.
undropStatusNoLe Status peut à nouveau être affiché et traité comme public.
tweet_editStatusYesRespecter et, le cas échéant, afficher la nouvelle édition.
user_deleteUserNoMasquer ou supprimer tous les Posts de l’utilisateur associé.
user_undeleteUserNoTous les Posts de l’utilisateur associé peuvent à nouveau être affichés et traités comme publics.
user_protectUserNoMasquer ou supprimer tous les Posts de l’utilisateur associé.
user_unprotectUserNoTous les Posts de l’utilisateur associé peuvent à nouveau être affichés et traités comme publics.
user_suspendUserNoMasquer ou supprimer tous les Posts de l’utilisateur associé.
user_unsuspendUserNoTous les Posts de l’utilisateur associé peuvent à nouveau être affichés et traités comme publics.
scrub_geoUserYesSupprimer toutes les géodonnées fournies par X pour tous les Posts de l’utilisateur antérieurs au Post spécifié dans le message scrub_geo. Notez que les Posts ultérieurs d’un utilisateur peuvent contenir des géodonnées qui peuvent être utilisées.
user_withheldUserYesMasquer les Posts de l’utilisateur associé dans les pays spécifiques listés dans le message user_withheld.
deleteFavoriteYesSupprimer le like/favori associé.

​
Exemples de payload

Voir ci-dessous des exemples de payload pour chaque événement de conformité décrit dans le tableau ci-dessus. Modification de Post 
{"tweet_edit":
   {
     "id": "1557445923210514432"
     "initial_tweet_id": "1557433858676740098",
     "edit_tweet_ids": ["1557433858676740098", "1557445923210514432"],
     "timestamp_ms": "1660155761384"
   }
 }
Suppression d’un Post
{
  "delete": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}
Post retenu
{
  "status_withheld": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220608",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "withheld_in_countries": [
      "XY"
    ],
    "timestamp_ms": "1432228155593"
  }
}
Abandon
{
  "drop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}
Annuler la suppression
{
  "undrop": {
    "status": {
      "id": 601430178305220600,
      "id_str": "601430178305220600",
      "user_id": 3198576760,
      "user_id_str": "3198576760"
    },
    "timestamp_ms": "1432228155593"
  }
}

​
Effacer les 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"
  }
}
Restauration 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"
  }
}
Protection de l’utilisateur
{
  "user_protect": {
    "id": 3182003550,
    "timestamp_ms": "1432228177137"
  }
}
Annuler la protection de l’utilisateur
{
  "user_unprotect": {
    "id": 2911076065,
    "timestamp_ms": "1432228180113"
  }
}
Suspension d’utilisateur
{
  "user_suspend": {
    "id": 3120539094,
    "timestamp_ms": "1432228194217"
  }
}
Réactivation d’un utilisateur
{
  "user_unsuspend": {
    "id": 3293130873,
    "timestamp_ms": "1432228193828"
  }
}

​
Intégration de Compliance Firehose

Compliance Firehose est une API de stream 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 manière dont ils sont générés sur X, veuillez consulter notre article Honoring User Intent on X. Il est important de noter que les événements Post et utilisateur sont diffusés séparément et que chacun doit être traité indépendamment (c.-à-d. la suppression d’un Post n’implique pas un événement utilisateur, et inversement). Plusieurs événements utilisateur ne sont pas nécessairement permanents et peuvent basculer indéfiniment entre différents états. Il s’agit notamment de : user_delete, user_undelete, user_protect, user_unprotect, user_suspend et user_unsuspend. Les user_delete sont suivis de status_delete 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, auquel cas les suppressions de tous ses Posts 30 jours plus tard n’auront pas lieu. user_suspend est une action qui demeure effective, sauf si l’utilisateur fait l’objet d’un événement user_unsuspend. Ces actions ne sont pas soumises à des modifications sur une période de 30 jours. Il n’est jamais approprié d’afficher directement des é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 uniquement destinés à maintenir la conformité et à respecter les actions des utilisateurs de X.

​
Intégration avec le Compliance Firehose

Pour intégrer le Compliance Firehose à votre système, vous devrez créer une intégration capable d’effectuer les opérations suivantes :
  1. Établir une connexion de streaming à chaque partition de l’API de streaming du Compliance Firehose
  2. Gérer des volumes de data élevés – découpler l’ingestion du stream du traitement aval à l’aide de processus asynchrones
  3. Se reconnecter automatiquement aux partitions du stream en cas de déconnexion, quelle qu’en soit la cause
  4. Traiter les événements de conformité pertinents pour les data de Post et d’utilisateur que vous avez stockées, conformément aux recommandations ci‑dessus

​
Respecter l’intention des utilisateurs sur X

Nous estimons que le respect de la vie privée et de l’intention des utilisateurs de X est essentiel à 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 de confidentialité à la disposition de ses utilisateurs, leur donnant la possibilité de maîtriser leur propre expérience sur X. En tant qu’entreprises consommatrices des data de X, nous avons la responsabilité collective de respecter la vie privée et les actions des utilisateurs finaux afin de préserver cet environnement de confiance et de respect. Il peut arriver différentes choses aux Posts et aux comptes d’utilisateurs qui influent 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 Post et de l’utilisateur. Ces actions incluent :

​
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 Posts de son compte. 
Pour en savoir plus, consultez À propos des Posts publics et protégés.
Supprimer le compteUn utilisateur X peut décider de supprimer son compte et tous les messages d’état associés à tout moment. X conserve les informations du compte pendant 30 jours après la suppression, au cas où l’utilisateur déciderait d’annuler la suppression et de réactiver son compte.
Effacer les données de géolocalisationUn utilisateur X peut supprimer toutes les données de localisation de ses Posts passés à tout moment. Cette opération est appelée « scrub geo ».
Suspendre le compteX se réserve le droit de suspendre les comptes qui enfreignent les Règles de X ou s’il existe un soupçon de piratage ou de compromission. Les suspensions de compte ne peuvent être levées (annulées) que par X.
Retenir le compteX se réserve le droit de restreindre de manière réactive l’accès à certains contenus dans un pays donné, ponctuellement. Un compte retenu ne peut être remis en ligne (non retenu) que par X. 
Pour en savoir plus, consultez Contenu retenu par pays.

​
Statut

ActionDescription
Supprimer un statutUn utilisateur X peut supprimer un statut à tout moment. Les statuts supprimés ne peuvent pas être restaurés et sont définitivement supprimés.
Restreindre un statutX se réserve le droit de restreindre de manière réactive l’accès à certains contenus dans un pays donné de temps à autre. Un statut restreint ne peut être rétabli que par X.
Pour plus d’informations, consultez Contenu restreint selon le pays.

​
Suivi des changements d’utilisateur et de statut

L’état d’un utilisateur ou d’un statut peut changer à tout moment suite à l’une des actions ci‑dessus, ce qui influe sur la manière dont les consommateurs des données X doivent gérer 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 utilisateur ou d’un statut a changé.

​
Référence de l’API

​
GET compliance/firehose

​
Méthodes

MéthodeDescription
GET /compliance/:streamSe connecter au stream de données

​
Authentification

Toutes les requêtes adressées à l’API Compliance Firehose doivent utiliser l’authentification HTTP Basic, établie à partir d’une combinaison valide d’adresse e‑mail et de mot de passe utilisée pour vous connecter à votre compte sur console.gnip.com. Les informations d’identification doivent être transmises dans l’en‑tête Authorization pour chaque requête.

​
GET /compliance/:stream

Établit une connexion persistante au stream de données Compliance firehose, via lequel les événements de conformité seront délivrés.
Request MethodHTTP GET
Connection TypeKeep-Alive
URLDisponible sur la page d’aide de l’API du stream de 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

Note : 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 stream.
CompressionGzip. Pour vous connecter au stream en utilisant 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 de lecture (read timeout) sur votre client et assurez-vous qu’il est défini sur une valeur supérieure à 30 secondes.
Support for Tweet editsToutes les modifications de Tweet déclenchent un événement de conformité « tweet_edit ». Voir la documentation Compliance Data Objects pour plus de détails.
Exemple de requête cURL L’exemple de requête suivant est effectué à 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’intégralité de ce stream.

​
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 accompagnés d’une chaîne avec des détails supplémentaires dans le corps. Pour toute réponse différente de 200, les clients doivent tenter de se reconnecter.
StatutTexteDéfinition
200SuccèsLa connexion a été ouverte avec succès et de nouvelles activités seront transmises au fur et à mesure de leur arrivée.
401Non autoriséL’authentification HTTP a échoué en raison d’identifiants invalides. Connectez-vous à console.gnip.com avec vos identifiants pour vérifier que vous les utilisez correctement dans votre requête.
406Non acceptableEn général, cela se produit lorsque votre client n’inclut pas correctement les en-têtes pour accepter l’encodage gzip depuis le stream, mais cela peut également se produire dans d’autres circonstances. Contiendra un message JSON similaire à « Cette connexion nécessite une compression. Pour activer la compression, envoyez un en-tête “Accept-Encoding: gzip” dans votre requête et soyez prêt à décompresser le stream lors de sa lecture côté client. »
429Limite de taux dépasséeVotre App a dépassé la limite des requêtes de connexion.
503Service indisponibleProblème de serveur X. Reconnectez-vous en utilisant une stratégie de repli exponentiel. 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 de l’utilisateur : Les messages liés aux utilisateurs exigent d’agir sur tous les Tweets de cet utilisateur. Par conséquent, puisque 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 le Tweet et l’utilisateur sur la base d’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 magasin de données local en conséquence.
  • Concevoir des schémas qui couvrent tous les statuts de conformité : Selon la manière dont les activités de conformité seront gérées dans différentes applications, il peut être nécessaire d’ajouter d’autres metadata au magasin de données. Par exemple, les consommateurs de données peuvent décider d’ajouter des metadata à une base de données existante afin de faciliter la restriction de l’affichage de contenu dans les pays concernés par un message status_withheld.
  • Gestion des suppressions de Retweet : Les Retweets sont un type particulier de Tweet où le message d’origine 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 d’origine (inclus dans l’objet imbriqué). Lorsqu’un message d’origine est supprimé, un message de suppression de Tweet est émis pour l’id d’origine. Des messages de suppression ultérieurs NE sont PAS émis pour tous les Retweets. La suppression de l’id d’origine suffit à supprimer tous les Retweets ultérieurs.
⌘I