Account Activity API : Enterprise

Cet endpoint a été mis à jour pour inclure les métadonnées d’édition de Publication. Pour en savoir plus sur ces métadonnées, consultez la page de notions de base « Edit Posts ». Cet endpoint est souvent utilisé avec les endpoints Direct Messages. Nous avons lancé de nouveaux endpoints Direct Messages v2. Notez que les Account Activity APIs Enterprise et Premium prennent en charge les messages v2 en tête-à-tête, mais ne prennent pas encore en charge les conversations de groupe.

Présentation générale Enterprise L’Account Activity API vous permet de vous abonner à des activités en temps réel liées à un compte utilisateur via des webhooks. Cela signifie que vous pouvez recevoir en temps réel des Publications, des Direct Messages et d’autres événements de compte provenant d’un ou plusieurs des comptes que vous possédez ou auxquels vous êtes abonné, via une seule connexion. Vous recevrez toutes les activités suivantes pour chaque abonnement utilisateur associé à votre enregistrement de webhook :

Types d’activité
* Publications (par l’utilisateur) * Suppressions de Publication (par l’utilisateur) * @mentions (de l’utilisateur) * Réponses (vers ou depuis l’utilisateur) * Retweets (par l’utilisateur ou de l’utilisateur) * Tweets cités (par l’utilisateur ou de l’utilisateur) * Retweets de Tweets cités (par l’utilisateur ou de l’utilisateur) * Likes (par l’utilisateur ou de l’utilisateur) * Follows (par l’utilisateur ou de l’utilisateur) * Unfollows (par l’utilisateur)	* Blocks (par l’utilisateur) * Unblocks (par l’utilisateur) * Mutes (par l’utilisateur) * Unmutes (par l’utilisateur) * Direct Messages envoyés (par l’utilisateur) * Direct Messages reçus (par l’utilisateur) * Indicateurs de saisie (vers l’utilisateur) * Accusés de lecture (vers l’utilisateur) * Révocations d’abonnement (par l’utilisateur)

Veuillez noter - Nous ne fournissons pas de données de la timeline d’accueil via l’Account Activity API. Veuillez utiliser GET statuses/home_timeline pour récupérer ces données.

Série de vidéos

Découvrez notre série de quatre vidéos sur l’API Account Activity pour vous mettre rapidement à niveau !

Résumé des fonctionnalités

Offre	Tarification	Nombre d’abonnements uniques	Nombre de webhooks	Fiabilité et reprise d’activité
Enterprise	Contacter l’équipe commerciale	Jusqu’à 500+	3+	Réessais et Replay

Des questions ? Vous rencontrez des erreurs ?
- Consultez notre page Questions fréquentes ou le guide de résolution des erreurs.
Explorez nos exemples de code :
- Tableau de bord Enterprise Account Activity API, une application web Node.js qui affiche les événements webhook en utilisant l’offre Enterprise de l’Account Activity API et inclut la fonctionnalité Replay.
- Le chatbot SnowBot, une application web Ruby basée sur les API Enterprise Account Activity et Direct Message.

Gérer les webhooks et les utilisateurs abonnés

⏱ 10 min de lecture L’API Enterprise Account Activity fournit des messages JSON via webhook chaque fois que des événements sont associés à des comptes X abonnés à votre service. X envoie ces activités à votre webhook enregistré. Dans les étapes suivantes, vous apprendrez à gérer les webhooks et les utilisateurs abonnés. Vous apprendrez à enregistrer, afficher et supprimer des webhooks, ainsi que des utilisateurs abonnés. Nous utiliserons de simples commandes cURL pour effectuer des requêtes vers les différents endpoints de l’API. cURL est un outil en ligne de commande permettant d’envoyer ou de récupérer des requêtes en utilisant la syntaxe d’URL. Vous aurez besoin de :

Une App X enregistrée - inscrivez-vous ici
Un Jeton Bearer - en savoir plus
Un webhook qui réussit un Challenge-Response Check (CRC) - en savoir plus
Un compte Enterprise - [postuler ici]https://developer.x.com/en/products/x-api/enterprise

Avant de commencer, nous vous recommandons de consulter notre dépôt GitHub ici, qui fournit une application web d’exemple et des scripts d’aide pour démarrer avec l’API Enterprise Account Activity de X

Gestion d’un webhook :

L’utilisation d’un webhook vous permet de vous abonner aux activités en temps réel liées à un compte utilisateur via une seule connexion.

Ajouter un webhook
Afficher un webhook
Supprimer un webhook

Commençons par enregistrer une nouvelle URL de webhook pour le contexte d’application donné.L’URL sera validée via une requête CRC avant l’enregistrement. Une fois que vous avez enregistré un webhook, veillez à noter l’ID du webhook, car vous en aurez besoin plus tard.Copiez la requête cURL suivante dans votre ligne de commande après avoir modifié les éléments suivants :

URL <URL> par ex. https://yourdomain.com/webhooks/twitter/
Consumer key <CONSUMER_KEY> par ex. xvz1evFS4wEEPTGEFPHBog

Access token <ACCESS_TOKEN> par ex. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request POST --url 'https://api.x.com/1.1/account_activity/webhooks.json?url=<URL>' --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<ACCESS_TOKEN>", oauth_version="1.0"'

Nous allons exécuter la commande suivante, qui renvoie toutes les URL de webhook enregistrées et leurs statuts pour l’application donnée.Copiez la requête cURL suivante dans votre ligne de commande après avoir modifié les éléments suivants :

Jeton Bearer <BEARER_TOKEN> par ex. AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...
--request GET --url https://api.x.com/1.1/account_activity/webhooks.json --header

Pour supprimer un webhook de la configuration de l’application fournie, copiez la requête cURL suivante dans votre ligne de commande après avoir modifié les éléments suivants :

ID du webhook <:WEBHOOK_ID> par ex. 1234567890
Consumer key <CONSUMER_KEY> par ex. xvz1evFS4wEEPTGEFPHBog
Access token <ACCESS_TOKEN> par ex. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
--request DELETE --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>.json --header

Gestion des utilisateurs abonnés :

Une fois que vous avez enregistré un webhook, vous pouvez ajouter un utilisateur abonné à l’API Account Activity pour commencer à recevoir les activités de son compte.

Ajouter un abonnement
Afficher les abonnements
Supprimer un abonnement

Nous allons commencer par abonner un utilisateur afin que vous receviez tous les types d’événements.Copiez la requête cURL suivante dans votre terminal après avoir modifié les éléments suivants :

Webhook ID <:WEBHOOK_ID> p. ex. 1234567890
Nom de la clé consommateur <CONSUMER_KEY> p. ex. xvz1evFS4wEEPTGEFPHBog

Jeton d’accès de l’utilisateur abonné <SUBSCRIBING_USER'S_ACCESS_TOKEN> p. ex. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request POST --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<SUBSCRIBING_USER'S_ACCESS_TOKEN>", oauth_version="1.0"'

Pour afficher la liste de tous les abonnements aux types d’activité pour un webhook spécifique, copiez la requête cURL suivante dans votre terminal après avoir modifié les éléments suivants :

Webhook ID <:WEBHOOK_ID> p. ex. 1234567890

Jeton Bearer <BEARER_TOKEN> p. ex. AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...

curl --request GET --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all/list.json --header 'authorization: Bearer <BEARER_TOKEN>'

Après la désactivation, tous les événements pour l’utilisateur ayant effectué la requête ne seront plus envoyés à l’URL du webhook.Pour désactiver un abonnement pour le contexte utilisateur et l’application fournis, copiez la requête cURL suivante dans votre terminal après avoir modifié les éléments suivants :

Webhook ID <:WEBHOOK_ID> p. ex. 1234567890
Clé consommateur <CONSUMER_KEY> p. ex. xvz1evFS4wEEPTGEFPHBog

Jeton d’accès de l’utilisateur abonné <SUBSCRIBING_USER'S_ACCESS_TOKEN> p. ex. 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request DELETE --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

Excellent travail ! Vous devriez maintenant être en mesure de gérer vos webhooks et les utilisateurs abonnés.

Articles de référence

Vue d’ensemble du Challenge-Response Check (CRC)
[Types de données de l’API Account Activity](/x-api/enterprise-gnip-2.0/fundamentals/account-activity#account-activity-data-object-structure
Gestion des webhooks et des abonnements

Une visite guidée vidéo de l’Account Activity API

Dans cette visite guidée vidéo, vous découvrirez les fonctionnalités des niveaux Premium et Enterprise de l’Account Activity API. À la fin de cette vidéo, vous aurez appris à utiliser les fonctionnalités suivantes :

Enregistrer un webhook
Ajouter un abonnement utilisateur
Supprimer un abonnement utilisateur
Recevoir les activités de compte
Rejouer les activités de compte

Vous avez des questions ? Vous rencontrez des erreurs ?
- Lisez notre foire aux questions ou le guide de résolution des erreurs.
Explorez notre code d’exemple :
- Enterprise Account Activity API dashboard, une application web Node qui affiche les événements de webhook à l’aide du niveau Enterprise de l’Account Activity API et inclut la fonctionnalité Replay.
- Le SnowBot chatbot, une application web Ruby basée sur les API Enterprise Account Activity et Direct Message.

Enterprise

Premiers pas avec les webhooks

L’Account Activity API est une API basée sur des webhooks qui envoie des événements de compte à une application web que vous développez, déployez et hébergez. Plusieurs détails d’infrastructure nécessitent votre attention avant de pouvoir commencer à recevoir des événements de webhook dans votre application qui consomme ces événements. Comme décrit ci-dessous, vous devrez créer une App X, obtenir l’accès à l’Account Activity API et développer une application web qui consomme des événements de webhook.

1. Créer une app X.

Créez une app X avec un compte développeur approuvé depuis la Console de développement. Si vous créez l’app au nom de votre entreprise, il est recommandé de la créer avec un compte X d’entreprise. Pour demander un compte développeur, cliquez ici.
Activez « Read, Write and Access direct messages » dans l’onglet permissions de la page de votre app.
Dans l’onglet « Keys and Access Tokens », notez la Consumer Key (API Key) et le Consumer Token (API Secret) de votre app.
Dans ce même onglet, générez l’Access Token et l’Access Token Secret de votre app. Vous aurez besoin de ces Access Tokens pour enregistrer l’URL de votre webhook, qui est l’endpoint où X enverra les événements de compte.
Si vous ne connaissez pas encore X Sign-in et le fonctionnement des contextes utilisateur avec la X API, consultez la section Obtaining Access Tokens. Lorsque vous ajoutez des comptes pour lesquels recevoir des événements, vous les abonnerez en utilisant les Access Tokens de ce compte.
Notez l’ID numérique de votre app, tel qu’il apparaît sur la page « Apps » de la Console de développement. Lorsque vous demandez l’accès à l’Account Activity API, vous aurez besoin de cet app ID.

2. Obtenir l’accès à l’API Account Activity

Après avoir créé une App X, l’étape suivante consiste à demander l’accès à l’API Account Activity. L’API Account Activity est uniquement disponible avec l’offre Enterprise, vous devrez donc soumettre une demande d’accès en utilisant le lien ci-dessous.

3. Développer une application consommatrice de webhooks

Une fois que vous avez obtenu l’accès à l’Account Activity API, vous devez développer, déployer et héberger une application web qui recevra les événements de webhook X.

Créez une application web avec une URL à utiliser comme webhook pour recevoir les événements. Il s’agit de l’endpoint déployé sur votre serveur pour écouter les événements de webhook X entrants.
- Le path de l’URI est entièrement à votre discrétion. Cet exemple serait valide : https://mydomain.com_/service/listen_
- Si vous écoutez des webhooks provenant de diverses sources, un modèle courant est : https://mydomain.com/webhook/twitter
- Notez que l’URL spécifiée ne peut pas comporter de port (https://mydomain.com:5000/NoWorkie).
Comme décrit dans notre guide Securing Webhooks, une première étape consiste à écrire du code qui reçoit une requête GET X Challenge Response Check (CRC) et y répond avec une réponse JSON correctement formatée.
Enregistrez votre URL de webhook. Vous ferez une requête POST vers l’endpoint /webhooks.json?url=. Lorsque vous faites cette requête, X enverra une requête CRC à votre application web. Lorsqu’un webhook est correctement enregistré, la réponse inclut un id de webhook. Cet id de webhook sera nécessaire plus tard pour effectuer certaines requêtes vers l’Account Activity API.
X enverra les événements de webhook de compte à l’URL que vous avez enregistrée. Assurez-vous que votre application web prend en charge les requêtes POST pour les événements entrants. Ces événements seront encodés en JSON. Voir ICI pour des exemples de payloads JSON de webhook.
Une fois votre application web prête, l’étape suivante consiste à ajouter les comptes pour lesquels vous souhaitez recevoir des activités. Lors de l’ajout (ou de la suppression) de comptes, vous effectuerez des requêtes POST qui font référence à l’id du compte. Consultez notre guide sur l’ajout d’abonnements pour plus d’informations.

4. Valider la configuration

Pour vérifier que votre App et votre webhook sont correctement configurés, ajoutez une Publication aux favoris parmi celles publiées par l’un des comptes X auxquels votre App est abonnée. Vous devriez recevoir un favorite_events via une requête POST vers l’URL de votre webhook pour chaque favori reçu par vos abonnés.
Notez qu’il peut s’écouler jusqu’à 10 secondes avant que les événements commencent à être délivrés après l’ajout d’un abonnement.

Notes importantes

Lors de l’enregistrement de l’URL de votre webhook, votre application web doit s’authentifier avec son consumer token et son secret et avec le user access token et le secret du propriétaire de l’App.
Tous les Messages Privés entrants seront délivrés via webhooks. Tous les Messages Privés envoyés via POST direct_messages/events/new (message_create) seront également délivrés via webhooks. Cela permet à votre application web d’être informée des Messages Privés envoyés via un autre client.
Notez que chaque événement de webhook inclut un user ID for_user_id qui indique pour quel abonnement l’événement a été délivré.
Si deux utilisateurs utilisent votre application web pour les Messages Privés dans une même conversation, votre webhook recevra deux événements en double (un pour chaque utilisateur). Votre application web doit en tenir compte.
Si vous avez plusieurs applications web partageant la même URL de webhook et le même utilisateur associé à chaque application, le même événement sera envoyé plusieurs fois à votre webhook (une fois par application web).
Dans certains cas, votre webhook peut recevoir des événements en double. Votre application de webhook doit être tolérante à ce comportement et effectuer une déduplication par event ID.
N’attendez pas qu’une réponse Quick Reply suive directement une demande. Un utilisateur peut ignorer une demande Quick Reply et répondre via un Message Privé traditionnel. L’utilisateur peut également envoyer une réponse Quick Reply à une demande à laquelle il n’a pas répondu plus tôt dans le fil de messages.
Voir le code d’exemple :
- Enterprise Account Activity API dashboard, une application web Node qui affiche les événements de webhook en utilisant l’offre Enterprise de l’Account Activity API et inclut la fonctionnalité Replay.
- Le chatbot SnowBot, une application web Ruby appuyée sur les APIs Account Activity et Direct Message. Ce code source inclut un script pour aider à configurer les webhooks de l’Account Activity API.

Sécurisation des webhooks

Les API de webhooks de X fournissent deux méthodes pour vérifier la sécurité de votre serveur de webhooks :

Les vérifications de type challenge-response permettent à X de confirmer que vous êtes bien propriétaire de l’application web qui reçoit les événements de webhook.
L’en-tête de signature dans chaque requête POST vous permet de confirmer que X est bien la source des webhooks entrants.

Vérifications Challenge-Response

Afin de vérifier que vous êtes à la fois le propriétaire de l’application et de l’URL du webhook, X effectuera une vérification Challenge-Response (CRC), à ne pas confondre avec un contrôle de redondance cyclique. Lorsqu’un CRC est envoyé, X effectue une requête GET vers votre application web avec un paramètre crc_token. À la réception de cette requête, votre application web doit construire un response_token chiffré à partir du paramètre crc_token et du Consumer Secret de votre application (détails ci‑dessous). Le response_token doit être encodé en JSON (voir l’exemple ci‑dessous) et renvoyé en moins de trois secondes. En cas de succès, un id de webhook sera renvoyé. Un CRC est envoyé lorsque vous enregistrez votre URL de webhook ; l’implémentation de votre code de réponse CRC est donc une première étape fondamentale. Une fois votre webhook établi, X déclenchera un CRC approximativement toutes les 24 heures à partir de la dernière fois où nous avons reçu une réponse valide. Votre application peut également déclencher un CRC au besoin en effectuant une requête PUT avec l’id de votre webhook. Déclencher un CRC est utile lorsque vous développez votre application de webhook, par exemple après le déploiement d’un nouveau code et le redémarrage de votre service. Le crc_token doit être considéré comme changeant à chaque requête CRC entrante et doit être utilisé comme message dans le calcul, où votre Consumer Secret est la clé. Si la réponse n’est pas renvoyée dans les 3 secondes ou devient invalide, les événements ne seront plus envoyés au webhook enregistré.

La requête CRC aura lieu :

Lorsqu’une URL de webhook est enregistrée.
Environ toutes les heures pour valider votre URL de webhook.
Vous pouvez déclencher manuellement un CRC en effectuant une requête PUT. Lorsque vous développez votre client de webhook, prévoyez de déclencher manuellement le CRC au fur et à mesure que vous développez votre réponse CRC.

Exigences concernant la réponse :

Un hachage HMAC SHA-256 encodé en base64, créé à partir du crc_token et de votre Consumer Secret d’App
Un response_token valide et un format JSON valide.
Une latence inférieure à 3 secondes.
Un code de réponse HTTP 200.

Bibliothèques HMAC par langage :

Exemple de génération de jeton de réponse en Python :

L’exemple suivant définit une route dans une application web Flask écrite en Python 2.7 qui répondra correctement à la vérification de la réponse au challenge.

import base64
import hashlib
import hmac
import json


\# Définit une route pour la requête GET
@app.route('/webhooks/twitter', methods=\['GET'\])
def webhook_challenge():

  # crée un hachage HMAC SHA-256 à partir du jeton entrant et de votre consumer secret
  sha256\_hash\_digest = hmac.new(TWITTER\_CONSUMER\_SECRET, msg=request.args.get('crc_token'), digestmod=hashlib.sha256).digest()

  # construit les données de réponse avec le hachage encodé en base64
  response = {
    'response\_token': 'sha256=' + base64.b64encode(sha256\_hash_digest)
  }

  # retourne une réponse JSON correctement formatée
  return json.dumps(response)

Exemple de réponse JSON :

Avec la route définie comme ci-dessus, votre application web doit renvoyer une réponse similaire à celle ci-dessous lorsque vous accédez à l’URL https://your-app-domain/webhooks/twitter?crc_token=foo dans votre navigateur web.

{
  "response_token": "sha256=x0mYd8hz2goCTfcNAaMqENy2BFgJJfJOb4PdvTffpwg="
}

Autres exemples :

ICI se trouve un exemple de méthode de réponse CRC écrite en Node.js.
ICI se trouve un exemple de méthode de réponse CRC écrite en Ruby (voir generate_crc_response et la route /GET qui reçoit les événements CRC).

Validation optionnelle de l’en-tête de signature

Lors de la réception d’une requête POST provenant de X, de l’envoi d’une requête GET pour créer un webhook ou de l’envoi d’une requête GET pour effectuer un CRC manuel, une signature de hachage est transmise dans les en-têtes sous la forme de x-twitter-webhooks-signature. Cette signature peut être utilisée pour vérifier que la source des données est X. La signature de hachage POST commence par sha256=, ce qui indique l’utilisation de HMAC SHA-256 pour signer votre Consumer Secret d’App X et le payload. Le hachage GET est calculé à partir de la chaîne de paramètres de requête crc_token=

token&amp;nonce=

nonce. Étapes pour valider une requête

Créez un hachage à l’aide de votre consumer secret et du corps du payload reçu.
Comparez le hachage créé avec la valeur x-twitter-webhooks-signature encodée en base64. Utilisez une méthode comme compare_digest pour réduire la vulnérabilité aux attaques par temporisation.

Recommandations de sécurité supplémentaires

Vous trouverez ci-dessous des recommandations de sécurité supplémentaires à prendre en compte pour votre application web. Le fait de ne pas les appliquer n’empêchera pas votre webhook de fonctionner, mais elles sont fortement recommandées par l’équipe X Information Security. Si vous n’êtes pas familier avec les recommandations ci-dessous, consultez votre administrateur système.

Blocs réseau agrégés de X

Pour plus de sécurité, vous pouvez ajouter les blocs réseau agrégés suivants à une liste d’autorisation (allowlist) :

199.59.148.0/22
199.16.156.0/22
192.133.77.0/26
64.63.15.0/24
64.63.31.0/24
64.63.47.0/24
202.160.128.0/24
202.160.129.0/24
202.160.130.0/24

Configurations de serveur recommandées

Note “A” au test ssllabs.com
Activer TLS 1.2
Activer la confidentialité persistante (Forward Secrecy)
Désactiver SSLv2
Désactiver SSLv3 (à cause de POODLE)
Désactiver TLS 1.0
Désactiver TLS 1.1
Désactiver la compression TLS
Désactiver les session tickets, sauf si vous faites une rotation des clés de tickets de session.
Régler l’option “ssl_prefer_server_ciphers” ou “SSLHonorCipherOrder” sur “on” dans la configuration SSL.
S’assurer que la liste de suites de chiffrement est une liste moderne, telle que : ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA

Gestion des webhooks et des abonnements

Création et modification de webhooks

Pour modifier des URL de webhook, vous devez supprimer votre webhook existant, puis en créer un nouveau. Notez que lorsque vous procédez ainsi, vous devrez réajouter les abonnements utilisateur au nouveau webhook.

Points de terminaison pour la gestion de la configuration des webhooks :


Method	Entreprise
Enregistre une URL de webhook / Génère un webhook_id	POST webhooks
Retourne toutes les URL de webhook et leurs statuts	GET webhooks
Supprime la configuration de webhook actuelle de l’application	DELETE webhooks/:webhook_id
Déclenche manuellement une requête CRC	PUT webhooks/:webhook_id

Pourquoi ne puis-je pas simplement mettre à jour l’URL du webhook ?

Pourquoi les configurations de webhook sont-elles immuables ? X prend la sécurité très au sérieux. Si l’URL de votre webhook est modifiée, il se peut que la consumer key et la consumer secret de votre application aient été compromises. En vous obligeant à créer une nouvelle configuration de webhook, vous êtes également obligé de vous réabonner aux événements de votre utilisateur. Cela nécessite l’utilisation de jetons d’accès qu’une partie malveillante est moins susceptible de posséder. Par conséquent, la probabilité qu’un tiers reçoive les informations privées de votre utilisateur est réduite.

Ajout et suppression d’abonnements utilisateur

Le niveau Enterprise prend en charge des milliers d’abonnements. Si vous avez déjà un chargé de compte, veuillez le contacter pour toute question. Pour demander l’accès aux API Enterprise, cliquez ici.

Points de terminaison de gestion des abonnements


Méthode	Enterprise
Ajouter un nouvel abonnement utilisateur	POST webhooks/:webhook_id/subscriptions/all
Récupérer un abonnement utilisateur	GET webhooks/:webhook_id/subscriptions/all
Renvoie une liste de tous les abonnements actifs	GET webhooks/:webhook_id/subscriptions/all/list
Désactive un abonnement utilisateur en utilisant OAuth en mode application-only	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json

Account Activity API : Enterprise

Veuillez noter : X doit activer l’accès à l’Account Activity API pour votre App développeur avant que vous puissiez commencer à utiliser l’API. À cette fin, veillez à communiquer l’App ID que vous avez l’intention d’utiliser pour l’authentification à votre responsable de compte ou à votre équipe d’assistance technique.

L’Account Activity API se compose d’un ensemble de points de terminaison qui vous permettent de créer et de gérer des abonnements utilisateur afin de recevoir en temps réel les activités de compte pour l’ensemble de vos comptes abonnés via une seule connexion. Deux méthodes d’authentification sont disponibles avec l’Account Activity API (OAuth 1.0a et Jeton Bearer OAuth 2.0). La méthode d’authentification que vous devez utiliser dépend du point de terminaison que vous utilisez.


Description	Endpoint	OAuth 1.0a (contexte utilisateur)	Jeton Bearer OAuth 2.0 (application uniquement)
Enregistrer une nouvelle URL de webhook pour le contexte d’application donné	POST account_activity/webhooks	✓
Retourner toutes les URL et leur statut pour l’application donnée	GET account_activity/webhooks		✓
Déclencher une vérification de la réponse au challenge (CRC) pour l’URL d’un webhook donné	PUT account_activity/webhooks/:webhook_id	✓
Abonner l’application aux événements du compte d’un utilisateur	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Retourner le nombre d’abonnements actuellement actifs	GET account_activity/subscriptions/count		✓
Vérifier si une configuration de webhook est abonnée aux événements d’un utilisateur	GET account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Retourner la liste des abonnements actuellement actifs	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
Supprimer un webhook	DELETE account_activity/webhooks/:webhook_id	✓
[OBSOLÈTE] Désactiver un abonnement pour le contexte utilisateur et l’application fournis	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Désactiver un abonnement en utilisant OAuth en mode application uniquement	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
Réacheminer des activités vers un webhook	POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json		✓

*_ L’authentification nécessite les jetons d’accès de l’utilisateur abonné. _ Pour les endpoints nécessitant une authentification OAuth 1.0a avec contexte utilisateur, vous devrez fournir les identifiants suivants pour authentifier la requête :

Consumer Keys (API Key et Secret)
Access Tokens (Access Token et Secret)

Dans le cas des trois endpoints suivants, vous effectuez des actions d’écriture dans le contexte de votre application (aucun utilisateur X n’est impliqué). Par conséquent, les Access Tokens que vous devez fournir sont ceux appartenant à votre App de développement. Ils peuvent être générés directement depuis la Console de développement, dans l’onglet « Keys and tokens » de votre App.

POST account_activity/webhooks : Enregistrer une nouvelle URL de webhook pour le contexte d’application donné
PUT account_activity/webhooks/:webhook_id : Déclencher une vérification de réponse au challenge (CRC) pour l’URL d’un webhook donné
DELETE account_activity/webhooks/:webhook_id : Supprimer un webhook

En revanche, dans le cas des trois endpoints suivants, vous effectuez une requête qui permet à votre application d’accéder à des données protégées au nom d’un utilisateur X (par exemple, des Messages privés). Vous devez donc fournir les jetons d’accès appartenant à l’utilisateur abonné en question. Les jetons d’accès requis peuvent être obtenus à l’aide du flux OAuth en 3 étapes (voir OAuth 1.0a : how to obtain a user’s Access Tokens). Ces endpoints ont été marqués d’un astérisque dans le tableau ci-dessus (*).

POST account_activity/webhooks/:webhook_id/subscriptions/all : Abonner l’application aux événements de compte d’un utilisateur
GET account_activity/webhooks/:webhook_id/subscriptions/all : Vérifier si une configuration de webhook est abonnée aux événements d’un utilisateur
DELETE account_activity/webhooks/:webhook_id/subscriptions/all : Désactiver un abonnement pour le contexte utilisateur et l’application fournis [DÉPRÉCIÉ]

Please note: Assurez-vous que votre App développeur est activée pour « Read, Write, and Direct Messages. » Vous pouvez modifier ce paramètre dans la section Projects & Apps de votre compte développeur, sous « App permissions » pour l’App développeur sélectionnée. Vous devrez régénérer les identifiants de votre App après avoir modifié les paramètres d’autorisations.

Une liste de tous les endpoints disponibles avec l’API Account Activity, y compris la description associée et des exemples de requêtes cURL illustrant l’implémentation de l’authentification, est disponible dans la documentation de Référence de l’API. Pour plus d’informations, consultez l’exemple d’application web et les scripts d’assistance de XDev pour commencer avec l’API Enterprise Account Activity.

Please note: X doit activer l’accès à l’API Account Activity pour votre App développeur avant que vous puissiez commencer à utiliser l’API. À cette fin, veillez à communiquer l’App ID que vous avez l’intention d’utiliser à des fins d’authentification à votre responsable de compte ou à votre équipe d’assistance technique.

L’API Account Activity se compose d’un ensemble d’endpoints qui vous permettent de créer et de gérer des abonnements d’utilisateurs afin de recevoir en temps réel les activités de compte pour tous vos comptes abonnés via une seule connexion. Deux méthodes d’authentification sont disponibles avec l’API Account Activity (OAuth 1.0a et Jeton Bearer OAuth 2.0). La méthode d’authentification que vous devez utiliser dépend de l’endpoint que vous utilisez.


Description	Endpoint	OAuth 1.0a (contexte utilisateur)	Jeton Bearer OAuth 2.0 (application uniquement)
Enregistrer une nouvelle URL de webhook pour le contexte d’application donné	POST account_activity/webhooks	✓
Renvoyer toutes les URL et leurs statuts pour l’application donnée	GET account_activity/webhooks		✓
Déclencher une vérification de réponse au défi (CRC) pour l’URL d’un webhook donné	PUT account_activity/webhooks/:webhook_id	✓
Abonner l’application aux événements de compte d’un utilisateur	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Renvoyer un décompte des abonnements actuellement actifs	GET account_activity/subscriptions/count		✓
Vérifier si une configuration de webhook est abonnée aux événements d’un utilisateur	GET account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Renvoyer une liste des abonnements actuellement actifs	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
Supprimer un webhook	DELETE account_activity/webhooks/:webhook_id	✓
[OBSOLÈTE] Désactiver un abonnement pour le contexte utilisateur et l’application fournis	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Désactiver un abonnement en utilisant OAuth en mode application uniquement	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
Renvoie les activités vers un webhook	POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json		✓

*_ L’authentification nécessite les jetons d’accès de l’utilisateur abonné._ Pour les points de terminaison qui nécessitent une authentification OAuth 1.0a en contexte utilisateur, vous devrez fournir les identifiants suivants pour authentifier la requête :

Consumer Keys (API Key et Secret)
Access Tokens (Access Token et Secret)

Dans le cas des trois points de terminaison suivants, vous effectuez des actions d’écriture dans le contexte de votre application (aucun utilisateur X n’est impliqué). Par conséquent, les Access Tokens que vous devez fournir sont ceux qui appartiennent à votre App de développeur. Ceux‑ci peuvent être générés directement depuis la Console de développement, sous l’onglet « Keys and tokens » de votre App.

POST account_activity/webhooks : Enregistrer une nouvelle URL de webhook pour le contexte d’application donné
PUT account_activity/webhooks/:webhook_id : Déclencher un contrôle CRC (challenge response check) pour l’URL d’un webhook donné
DELETE account_activity/webhooks/:webhook_id : Supprimer un webhook

En revanche, pour les trois endpoints suivants, vous effectuez une requête qui permet à votre application d’accéder à des données protégées pour le compte d’un utilisateur X (par exemple, les Direct Messages). Vous devez donc fournir les Access Tokens appartenant à l’utilisateur abonné en question. Les Access Tokens requis peuvent être obtenus à l’aide du flux OAuth en 3 étapes (voir OAuth 1.0a: how to obtain a user’s Access Tokens). Ces endpoints sont marqués d’un astérisque dans le tableau ci-dessus (*).

POST account_activity/webhooks/:webhook_id/subscriptions/all : Abonner l’application aux événements de compte d’un utilisateur
GET account_activity/webhooks/:webhook_id/subscriptions/all : Vérifier si une configuration de webhook est abonnée aux événements d’un utilisateur
DELETE account_activity/webhooks/:webhook_id/subscriptions/all : Désactiver un abonnement pour le contexte utilisateur et l’application fournis [DEPRECATED]

Remarque : Assurez-vous que votre App développeur est activée pour « Read, Write, and Direct Messages ». Vous pouvez modifier ce paramètre dans la section Projects & Apps de votre compte développeur, sous « App permissions » pour l’App développeur sélectionnée. Vous devrez régénérer les identifiants de votre App après avoir modifié les paramètres d’autorisation.

Une liste de tous les endpoints disponibles avec l’API Account Activity, y compris la description associée et des exemples de requêtes cURL avec des exemples d’implémentation de l’authentification, est disponible dans la documentation de référence de l’API. Pour plus d’informations, consultez l’application web d’exemple et les scripts d’aide de XDev pour commencer avec l’API Enterprise Account Activity.

Réessais

Enterprise L’un des avantages du niveau Enterprise de l’Account Activity API est un mécanisme de réessai pour les événements de webhook. Si un code de réponse HTTP 200 « success » n’est pas reçu, le serveur X déclenche un mécanisme de réessai, renvoyant l’événement de webhook jusqu’à trois fois sur une période de cinq minutes. Ce service de réessai des événements de webhook contribue à garantir la fiabilité et la récupération des événements lorsque des problèmes de réseau surviennent et pendant les interruptions de service et les déploiements côté client.

Que sont les retries ?

L’Account Activity API fournit une fonctionnalité de nouvelle tentative (retry) lorsque l’app web du client ne renvoie pas une réponse 200 « success » pour un événement de webhook d’activité de compte. Lorsque le côté client ne confirme pas la bonne réception d’un événement, X part du principe que l’événement n’a pas été reçu. Si une réponse non 200 est reçue, si aucune réponse n’est reçue dans les trois secondes, ou si nous ne recevons pas de réponse du tout, nous renvoyons la requête et la laissons ouverte pendant trois secondes. Cela signifie que vous disposez d’environ cinq secondes réparties sur deux tentatives pour répondre et ainsi recevoir l’activité que nous essayons d’envoyer vers votre URL de webhook. Dans le cas où votre serveur ne répond pas ou renvoie une erreur transitoire, nous réessaierons pendant cinq minutes. Il y aura au total trois tentatives de retry pour confirmer la validation. Cela offre une redondance et garantit que vous recevez tous les événements de webhook. Notez que les abonnements avec retries recevront des événements retentés pour n’importe quelles activités de tous les utilisateurs abonnés sur leur webhook. Si vous ne confirmez pas la validation au cours de ces huit tentatives, l’activité ne sera plus disponible via l’Account Activity API.

Chronologie des tentatives

L’Account Activity API effectuera jusqu’à trois nouvelles tentatives sur une période de cinq minutes, jusqu’à réception d’une réponse 200. Reportez-vous au tableau ci-dessous pour plus de détails. Au bout d’environ cinq minutes, l’activité ne peut plus être renvoyée via l’Account Activity API. Vous devrez utiliser d’autres endpoints X pour récupérer les données manquantes. Par exemple, les search APIs peuvent être utilisées pour récupérer les Publications, Retweets, Tweets cités, mentions et réponses concernés. Les Messages privés manqués peuvent être récupérés avec cet endpoint.

Chronologie des réessais


Activité créée : requête POST vers l’URL du webhook depuis l’Account Activity API, qui expire au bout de trois secondes.
Attendez trois secondes après la fin du délai d’expiration précédent, puis effectuez une requête POST vers l’URL du webhook depuis l’Account Activity API, qui expirera au bout de trois secondes.
Attendez 27 secondes après la fin du délai d’expiration précédent, puis effectuez une requête POST vers l’URL du webhook depuis l’Account Activity API, qui expirera au bout de trois secondes.
Attendez 242 secondes après la fin du délai d’expiration précédent, puis effectuez une requête POST vers l’URL du webhook depuis l’Account Activity API, qui expirera au bout de trois secondes.
L’Account Activity API cessera ensuite de tenter d’effectuer des requêtes POST. Le Client doit utiliser d’autres endpoints X pour récupérer les données.

Structure de l’objet de données Account Activity

Objet	Détails
for_user_id	Identifie l’abonnement utilisateur auquel l’événement est lié.
is_blocked_by	(conditionnel) Affiché uniquement lorsqu’un autre utilisateur mentionne votre utilisateur abonné. Inclus avec la valeur true uniquement pour les événements de mention de Publication.
source	L’utilisateur qui effectue l’activité. Par exemple, l’utilisateur qui suit, bloque ou met en sourdine est l’utilisateur source.
target	L’utilisateur auquel s’applique l’activité. Par exemple, l’utilisateur qui est suivi, bloqué ou mis en sourdine est l’utilisateur cible.

Activités disponibles

Type de message	Détails
tweet_create_events	Charge utile de statut de Publication générée lorsque l’une des actions suivantes est effectuée par ou à l’utilisateur abonné : Publications, Retweets, Réponses, @mentions, QuoteTweets, Retweet de QuoteTweets.
favorite_events	Événement de favori (mention « J’aime ») avec l’utilisateur et la cible.
follow_events	Événement de suivi avec l’utilisateur et la cible.
unfollow_events	Événement de désabonnement avec l’utilisateur et la cible.
block_events	Événement de blocage avec l’utilisateur et la cible.
unblock_events	Événement de déblocage avec l’utilisateur et la cible.
mute_events	Événement de mise en sourdine avec l’utilisateur et la cible.
unmute_events	Événement d’annulation de la mise en sourdine avec l’utilisateur et la cible.
user_event	Événements de révocation envoyés lorsqu’un utilisateur retire l’autorisation de l’application et que l’abonnement est automatiquement supprimé.
direct_message_events	Statut de message privé avec l’utilisateur et la cible lorsqu’un message privé est envoyé ou reçu.
direct_message_indicate_typing_events	Événement de saisie de message privé avec l’utilisateur et la cible.
direct_message_mark_read_events	Événement de lecture de message privé avec l’utilisateur et la cible.
tweet_delete_events	Notification de Publications supprimées afin de faciliter le respect des obligations de conformité.

Exemples de charge utile Reportez-vous aux exemples de charge utile ci-dessous pour chaque événement Account Activity décrit dans le tableau ci-dessus.

tweet_create_events (Publications, Retweets, Réponses, Tweets cités)

{
	"for_user_id": "2244994945",
	"tweet_create_events": [
	  {
		<Tweet Object>
	  }
	]
}

tweet_create_events (@mentions)

{
	"for_user_id": "2244994945",
	"user_has_blocked": "false",
	"tweet_create_events": [
	  {
		<Tweet Object>
	  }
	]
}

favorite_events

{
	"for_user_id": "2244994945",
	"favorite_events": [{
		"id": "a7ba59eab0bfcba386f7acedac279542",
		"created_at": "Mon Mar 26 16:33:26 +0000 2018",
		"timestamp_ms": 1522082006140,
		"favorited_status": {
			<Tweet Object>
		},
		"user": {
			<User Object>
		}
	}]
}

follow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "follow",
			"created_timestamp": "1517588749178",
			"target": {
				<User Object >
			},
			"source": {
				< User Object >
			}
		]
	}
}

unfollow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "unfollow",
			"created_timestamp": "1517588749178",
			"target": {
				<User Object >
			},
			"source": {
				< User Object >
			}
		]
	}
}

block_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "block",
		"created_timestamp": "1518127020304",
		"source": {
			<User Object>
		},
		"target": {
			<User Object>
		}
	}]
}

unblock_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "unblock",
		"created_timestamp": "1518127020304",
		"source": {
			<User Object>
		},
		"target": {
			<User Object>
		}
	}]
}

mute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "mute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<User Object>
			},
			"target": {
				<User Object>
			}
		}
	]
}

unmute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "unmute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<User Object>
			},
			"target": {
				<User Object>
			}
		}
	]
}

user_event

{
	"user_event": {
		"revoke": {
			"date_time": "2018-05-24T09:48:12+00:00",
			"target": {
				"app_id": "13090192"
			},
			"source": {
				"user_id": "63046977"
			}
		}
	}
}

direct_message_events

{
  	"for_user_id": "4337869213",
	"direct_message_events": [{
		"type": "message_create",
		"id": "954491830116155396",
		"created_timestamp": "1516403560557",
		"message_create": {
			"target": {
				"recipient_id": "4337869213"
			},
			"sender_id": "3001969357",
			"source_app_id": "13090192",
			"message_data": {
				"text": "Hello World!",
				"entities": {
					"hashtags": [],
					"symbols": [],
					"user_mentions": [],
					"urls": []
				}
			}
		}
	}],
	"apps": {
		"13090192": {
			"id": "13090192",
			"name": "FuriousCamperTestApp1",
			"url": "https://x.com/furiouscamper"
		},
		"users": {},
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE les-opinions-sont-les-miennes",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 22,
			"friends_count": 45,
			"statuses_count": 494,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		},
		"4337869213": {
			"id": "4337869213",
			"created_timestamp": "1448312972328",
			"name": "Harrison Test",
			"screen_name": "Harris_0ff",
			"location": "Burlington, MA",
			"protected": false,
			"verified": false,
			"followers_count": 8,
			"friends_count": 8,
			"profile_image_url": "null",
			"statuses_count": 240,
			"profile_image_url_https": "https://abs.twimg.com/sticky/default_profile_images/default_profile_normal.png"
		}
	}
}

direct_message_indicate_typing_events

{
	"for_user_id": "4337869213",
	"direct_message_indicate_typing_events": [{
		"created_timestamp": "1518127183443",
		"sender_id": "3284025577",
		"target": {
			"recipient_id": "3001969357"
		}
	}],
	"users": {
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE les-opinions-sont-les-miennes",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 23,
			"friends_count": 47,
			"statuses_count": 509,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		},
		"3284025577": {
			"id": "3284025577",
			"created_timestamp": "1437281176085",
			"name": "Bogus Bogart",
			"screen_name": "bogusbogart",
			"protected": true,
			"verified": false,
			"followers_count": 1,
			"friends_count": 4,
			"statuses_count": 35,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/763383202857779200/ndvZ96mE_normal.jpg"
		}
	}
}

direct_message_mark_read_events

{
	"for_user_id": "4337869213",
	"direct_message_mark_read_events": [{
		"created_timestamp": "1518452444662",
		"sender_id": "199566737",
		"target": {
			"recipient_id": "3001969357"
		},
		"last_read_event_id": "963085315333238788"
	}],
	"users": {
		"199566737": {
			"id": "199566737",
			"created_timestamp": "1286429788000",
			"name": "Le Braat",
			"screen_name": "LeBraat",
			"location": "Denver, CO",
			"description": "data by day @X, design by dusk",
			"protected": false,
			"verified": false,
			"followers_count": 299,
			"friends_count": 336,
			"statuses_count": 752,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/936652894371119105/YHEozVAg_normal.jpg"
		},
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opinions-are-my-own",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 23,
			"friends_count": 48,
			"statuses_count": 510,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		}
	}
}

tweet_delete_events

{
    "for_user_id": "930524282358325248",
    "tweet_delete_events": [
{
        "status": {
            "id": "1045405559317569537",
            "user_id": "930524282358325248"
        },
        "timestamp_ms": "1432228155593"
    }
   ]
}

API Account Activity Replay

Enterprise L’API Account Activity Replay est un outil de récupération de données qui vous permet de récupérer des événements jusqu’à cinq jours en arrière. Elle doit être utilisée pour récupérer des données dans les scénarios où votre serveur de webhook rate des événements : que ce soit en raison de déconnexions plus longues que la fenêtre de nouvelle tentative, ou dans les scénarios de reprise après sinistre où vous avez besoin de quelques jours pour rétablir votre système à la normale. L’API Account Activity Replay a été développée pour tout scénario dans lequel vous n’ingérez pas les activités pendant une certaine période. Elle envoie les activités au même webhook utilisé pour la diffusion en temps réel d’origine des activités. Ce produit est un outil de récupération et non un outil de reconstitution, ce qui signifie que les événements ne seront rejoués que si une tentative de livraison antérieure a eu lieu. L’API Account Activity Replay ne peut pas livrer d’événements pour une période antérieure au moment de création d’un abonnement.

Utilisation de l’API Account Activity Replay

Si votre compte est configuré avec la fonctionnalité Replay, vous pouvez effectuer des requêtes de manière similaire aux requêtes vers l’API Account Activity. Il est important de noter que votre requête doit spécifier un paramètre webhook id pour indiquer les activités du webhook que vous souhaitez rejouer. En d’autres termes, une requête Replay demande à l’API Account Activity Replay de récupérer des événements entre une date et une heure de début et une date et une heure de fin, sur la base du webhook id et de l’application id. Veuillez noter que l’heure attendue est l’heure UTC. Ces activités sont envoyées via le webhook enregistré associé à l’id, à un taux pouvant atteindre 2 500 événements par seconde. Gardez également à l’esprit qu’une seule tâche Replay par webhook peut être en cours d’exécution à la fois, même si tous les abonnements qui étaient actifs pendant l’intervalle de date/heure spécifié pour ce webhook seront rejoués. Les événements sont envoyés en commençant par la première minute (la plus ancienne) de la période de temps spécifiée, puis en continuant dans l’ordre chronologique (autant que possible) jusqu’à la livraison de la dernière minute. À ce moment-là, Replay enverra un événement de fin de travail au webhook. Comme nous travaillons de façon chronologique pour la livraison des activités, s’il y a peu ou pas de résultats correspondants près de l’heure de début, il y aura probablement un laps de temps avant la livraison des premiers résultats.

Limitations

Replay est conçu comme un outil permettant de récupérer facilement des activités jusqu’à cinq jours en arrière, mais il ne renverra pas d’événements antérieurs au moment de création d’un abonnement. Par exemple, si vous avez ajouté un nouvel abonnement il y a trois jours et exécuté une tâche Replay avec une fenêtre couvrant les cinq jours précédant aujourd’hui, vous ne recevrez des données que pour les trois jours durant lesquels ce nouvel abonnement était actif.

Disponibilité des données et types

Les activités de l’API Account Activity Replay sont disponibles pendant cinq jours à compter du lancement de la requête, de nouvelles données devenant disponibles environ 10 minutes après la création d’une activité donnée. Vous pourrez effectuer des requêtes en spécifiant une période dans cette fenêtre de cinq jours à l’aide des paramètres from_date et to_date dans la requête. Les événements qui ont été initialement envoyés avant que vous n’ayez accès à Replay ne peuvent pas être rejoués. Par exemple, si votre compte a été activé pour l’accès à l’API Account Activity Replay le 1er juin 2019 à 15 h 30 UTC, vous ne pourrez pas utiliser Replay pour récupérer des événements antérieurs à cette date et heure. Passez à la Référence de l’API Account Activity Replay

Introduction à la migration

Nous avons mis hors service les produits Site Streams, User Streams et la version bêta standard de l’Account Activity API - DM Only en 2018. Si vous utilisiez ces produits, veillez à migrer vers la version premium ou enterprise de l’Account Activity API. **Nous avons également mis hors service les anciens endpoints Direct Message. Si vous utilisiez ces endpoints, veillez à migrer soit vers les nouveaux endpoints DM, soit vers la version premium ou enterprise de l’Account Activity API. ** Veuillez consulter cette annonce pour en savoir plus. Voici les endpoints qui seront affectés par ces changements :

User Streams
Site Streams
GET direct_messages
GET direct_messages/sent
GET direct_messages/show
POST direct_messages/new
POST direct_messages/destroy

Nous disposons de nouveaux endpoints et services qui offrent un accès similaire et, pour les Direct Messages, des fonctionnalités supplémentaires :

Account Activity API enterprise et premium
GET direct_messages/events/list
GET direct_messages/events/show
POST direct_messages/events/new
POST direct_messages/events/destroy

Pour vous aider à effectuer une migration en douceur vers ces nouveaux endpoints et services, nous proposons deux guides de migration :

Guide de migration Account Activity API pour ceux qui passent de User Streams et Site Streams à notre nouveau service basé sur des webhooks
Guide de migration Direct Message pour ceux qui migrent entre les endpoints REST Direct Message

En outre, nous proposons une série de vidéos sur l’Account Activity API et la façon de commencer. Enfin, nous mettons à disposition des exemples de code pour approfondir votre compréhension et vous aider à démarrer rapidement :

L’Account Activity Dashboard est une application web Node.js d’exemple, avec des scripts d’assistance pour démarrer avec l’Account Activity API.
SnowBot est un chatbot d’exemple utilisant l’Account Activity API et les endpoints REST Direct Message. Il est écrit en Ruby, utilise le framework web Sinatra et est déployé sur Heroku.

Guide de migration : passer de User Streams/Site Streams à l’Account Activity API

Depuis le 23 août 2018, nous avons mis fin à Site Streams et User Streams. Assurez-vous de migrer vers l’Account Activity API. Veuillez consulter cette annonce pour en savoir plus. Ce guide est conçu pour vous aider à migrer des anciennes API User Streams et Site Streams vers leur remplaçante, l’Account Activity API. Ci-dessous, vous trouverez un résumé des changements, une liste des nouvelles fonctionnalités, ainsi que les principales différences et considérations pour vous aider dans la transition. Pour obtenir des conseils sur la migration à partir des endpoints DM de base, veuillez consulter le guide de migration des Direct Messages.

Résumé des modifications

L’API Account Activity vous enverra des événements pour les comptes authentifiés et abonnés au moyen de webhooks, plutôt que via une connexion de streaming comme avec User Streams et Site Streams.

APIs obsolètes

GET user GET site (y compris les flux de contrôle : GET site/c/:stream_id, GET site/c/:stream_id/info.json, GET site/c/:stream_id/friends/ids.json, POST site/c/:stream_id/add_user.json, POST /site/c/:stream_id/remove_user.json)

API de remplacement

Enterprise Account Activity API - Toutes les activités

Différences et considérations de migration

Format de l’API : La nouvelle Account Activity API fonctionne différemment de User Streams et Site Streams. Vous devrez modifier votre application web pour recevoir des données via des webhooks. Vous trouverez plus d’informations sur les webhooks ici. Données disponibles : Une autre différence clé que vous remarquerez concerne les données transmises. X n’enverra plus d’événements en provenance des personnes que vous suivez sur X (c’est‑à‑dire votre fil d’accueil). Il s’agit d’un changement intentionnel et nous ne prévoyons pas de le modifier à l’avenir. Fiabilité : Contrairement au streaming, les webhooks permettent la confirmation de la livraison et offrent des options pour retenter l’envoi des activités envoyées en POST qui n’atteignent pas l’URL du webhook. Cela offre davantage de garanties que l’application reçoit toutes les activités concernées, même en cas de brèves interruptions de connexion ou de périodes d’indisponibilité.

Nouvelles fonctionnalités

L’Account Activity API propose de nombreuses nouvelles fonctionnalités, notamment le fait que les données sont désormais transmises via des webhooks plutôt que par streaming. Les webhooks offrent de nombreux avantages par rapport au streaming, les principaux étant la rapidité et la fiabilité. L’API vous enverra les données sous forme d’événements JSON dès qu’elles seront disponibles et vous n’aurez plus besoin de maintenir une connexion active ni de sonder l’endpoint. Cela limite le besoin de mécanismes de redondance et améliore l’efficacité globale. Vous trouverez davantage d’informations sur les webhooks dans la documentation technique.

Gestion des abonnements utilisateur

L’API Account Activity permet de configurer plusieurs abonnements pour un même webhook enregistré. Cela permet d’acheminer les activités de plusieurs abonnements utilisateur vers le même emplacement, de manière similaire à l’architecture Site Streams, mais avec des webhooks. Vous pouvez ainsi suivre vos abonnements, en ce qui concerne vos limites d’abonnement, indépendamment de la connexion du webhook. Cela permet également de faire évoluer votre intégration, en passant d’un ou de quelques abonnements à des milliers d’abonnements pour un seul webhook.

Procédure de migration

Suivez les étapes ci-dessous pour migrer facilement de l’API Site Streams vers l’API Account Activity

Étape 1 : Choisir une formule Selon la manière dont vous utilisez actuellement User Streams ou Site Streams, vous devriez envisager de passer à la version enterprise ou premium de l’API Account Activity. Prenez en compte le nombre d’applications ou d’utilisateurs autorisés que vous prenez actuellement en charge et adaptez-vous au volume et au niveau de fiabilité nécessaires. Lors du choix de la formule la mieux adaptée à vos besoins, quelques points importants sont à prendre en considération :

Nombre de webhooks nécessaires
Abonnements/utilisateurs autorisés actuels/prévus gérés sur votre application
Nombre actuel d’applications client X
Niveau de support souhaité de la part de X (support via forum ou support enterprise géré en mode 1:1)
Prix de chaque formule

Étape 2 : Vérifier la configuration de votre App X dans la Console de développement L’App X actuellement utilisée pour User Streams ou Site Streams sera répertoriée pour l’utilisateur propriétaire au sein de la Console de développement. Cette App X peut également être utilisée pour l’API Account Activity afin de conserver les utilisateurs autorisés pour cette application. Une nouvelle App peut également être créée, et les utilisateurs peuvent être de nouveau autorisés pour cette nouvelle App si nécessaire. Si vous créez une nouvelle App pour le compte d’une entreprise, il est recommandé de créer l’App avec un compte X @handle d’entreprise.

Activez « Read, Write and Access direct messages » dans l’onglet permissions de la page de votre App X. Notez que la modification de ces paramètres n’est pas rétroactive ; tout utilisateur déjà autorisé conservera les paramètres d’autorisation en vigueur au moment où il a été autorisé. Si un utilisateur ne vous a pas déjà donné l’accès en lecture, écriture et messages privés, vous devrez lui demander de réautoriser votre application.
Si vous ne connaissez pas X Sign-in et le fonctionnement des contextes utilisateur avec la X API, consultez Obtaining Access Tokens.
Générez des jetons d’accès pour le propriétaire de l’App X en bas de l’onglet « Keys and Tokens ». Sur ce même onglet, notez votre Consumer Key, Consumer Secret, Access Token et Access Token Secret. Vous en aurez besoin pour utiliser l’API.
Générez un Jeton Bearer à l’aide de votre Consumer Key et de votre Consumer Secret pour les méthodes d’API application-only.

Étape 3 : Configurer vos webhooks

Créez une application web avec un endpoint à utiliser comme webhook pour recevoir les événements (par exemple : https://your_domain.com/webhook/twitter ou https://webhooks.your_domain.com).
Utilisez votre Consumer Key, Consumer Secret, Access Token et Access Token Secret lors de la création de votre webhook. Notez que votre endpoint doit retourner une réponse JSON contenant un response_token qui est un hachage HMAC SHA-256 encodé en base64, créé à partir du crc_token et du Consumer Secret de votre App.
Consultez la documentation Securing Webhooks, en portant une attention particulière aux exigences liées au Challenge Response Check (CRC).
Assurez-vous que votre webhook prend en charge les requêtes POST pour les événements entrants et les requêtes GET pour le CRC.
Assurez-vous que votre webhook présente une faible latence (moins de 3 secondes pour répondre aux requêtes POST).

Étape 4 : Valider la configuration de votre webhook

Les API de webhooks sécurisent vos webhooks de deux manières :

- Exiger des Challenge Response Checks pour vérifier que le propriétaire du webhook est le propriétaire de l’application web. - Inclure un en-tête de signature dans chaque requête POST afin que votre application web puisse valider la source.

Afin de vérifier que vous êtes à la fois le propriétaire de l’application web et de l’URL du webhook, X effectuera un Challenge Response Check (CRC), à ne pas confondre avec un contrôle de redondance cyclique.
Une requête GET avec un paramètre nommé crc_token sera envoyée à l’URL de votre webhook. Votre endpoint doit retourner une réponse JSON contenant un response_token qui est un hachage HMAC SHA-256 encodé en base64, créé à partir du crc_token et du Consumer Secret de votre App.
Le crc_token est susceptible de changer pour chaque requête CRC entrante. Le crc_token doit être utilisé comme message dans le calcul, où votre Consumer Secret est la clé.
Si la réponse est invalide, l’envoi des événements au webhook enregistré cessera.

Étape 5 : Créer des abonnements pour chaque utilisateur User Streams ou Site Streams autorisé Conversion vers l’API Account Activity à partir de User Streams :

Générez la liste de vos abonnements utilisateur actuels sur User Streams
Configurez vos nouveaux abonnements à l’Account Activity API à l’aide de la requête POST account_activity/all/:env_name/subscriptions
Confirmez vos abonnements à l’Account Activity API à l’aide de la requête _GET account_activity/all/:env_name/subscriptions/list _

Conversion vers l’Account Activity API depuis Site Streams : (à l’aide des flux de contrôle) :

Générez la liste de vos abonnements actuels sur Site Streams à l’aide de la requête GET /1.1/site/c/:stream_id/info.json
Configurez vos nouveaux abonnements à l’Account Activity API à l’aide de la requête POST account_activity/all/:env_name/subscriptions
Confirmez vos abonnements à l’Account Activity API à l’aide de la requête _GET account_activity/all/:env_name/subscriptions/list _

Enregistrement d’un webhook et création d’abonnements (sans migration depuis Site Streams ou User Streams)

Enregistrez l’URL de votre webhook avec votre App à l’aide de POST webhooks et recevez un webhook_id.
Utilisez le webhook_id renvoyé pour ajouter des abonnements utilisateur avec POST webhooks/:webhook_id/subscriptions/all.

Le tableau de bord Account Activity (exemple d’application pour l’API Account Activity)

Nous avons créé une application d’exemple pour rendre les tests de l’API Account Activity un peu plus rapides :

Téléchargez l’application d’exemple Account Activity Dashboard ici (elle utilise Node.js)
Suivez les instructions du README pour installer et lancer l’application
Une fois l’application lancée, vous pouvez utiliser l’interface utilisateur pour configurer facilement votre webhook et créer un nouvel abonnement

Activités disponibles

Message Type	Détails
tweet_create_events	Charge utile de statut de Publication lorsque l’une des actions suivantes est effectuée par ou à l’utilisateur abonné : Publications, Retweets, réponses, @mentions, Tweets cités
favorite_events	Événement de mise en favori (like) incluant l’utilisateur et la cible.
follow_events	Événement d’abonnement incluant l’utilisateur et la cible.
block_events	Événement de blocage incluant l’utilisateur et la cible.
mute_events	Événement de mise en sourdine incluant l’utilisateur et la cible.
direct_message_events	Événement de message privé incluant l’utilisateur et la cible.
direct_message_indicate_typing_events	Événement de saisie de message privé incluant l’utilisateur et la cible.
direct_message_mark_read_events	Événement de lecture de message privé incluant l’utilisateur et la cible.

Types de messages de streaming obsolètes


Lignes vides	Les lignes vides ne seront plus transmises dans l’Account Activity API, car elles étaient utilisées comme messages de maintien de connexion dans User Streams et Site Streams.
Notifications de limite	Les notifications de limite ne seront plus envoyées à un webhook donné. À la place, les utilisateurs peuvent appeler l’API pour obtenir l’utilisation actuelle des handles disponibles. Ces informations seront ajoutées à la Console de développement à un moment donné dans le futur.
Messages de déconnexion	Les notifications de déconnexion ne seront plus nécessaires, car les webhooks ne reposent pas sur une connexion active.
Avertissements de blocage	Les avertissements de blocage ne seront plus nécessaires, car les webhooks ne reposent pas sur une connexion active capable de gérer un grand nombre de messages entrants.
Liste d’amis	Les listes d’amis ne seront plus envoyées de manière proactive. Il y aura désormais un point de terminaison REST pour obtenir ces informations.

Types d’événements obsolètes


Description	Nom de l’événement	Source	Cible	Objet cible
L’utilisateur supprime une publication	delete	Utilisateur actuel	Utilisateur actuel	Publication
Un utilisateur suivi supprime une publication	delete	Utilisateur suivi	Utilisateur suivi	Publication
L’utilisateur retire une publication de ses favoris	unfavorite	Utilisateur actuel	Auteur de la publication	Publication
La publication de l’utilisateur est retirée des favoris	unfavorite	Utilisateur qui retire le favori	Utilisateur actuel	Publication
L’utilisateur ne suit plus quelqu’un	unfollow	Utilisateur actuel	Utilisateur suivi	Null
L’utilisateur crée une liste	list_created	Utilisateur actuel	Utilisateur actuel	Liste
L’utilisateur supprime une liste	list_destroyed	Utilisateur actuel	Utilisateur actuel	Liste
L’utilisateur modifie une liste	list_updated	Utilisateur actuel	Utilisateur actuel	Liste
L’utilisateur ajoute quelqu’un à une liste	list_member_added	Utilisateur actuel	Utilisateur ajouté	Liste
L’utilisateur est ajouté à une liste	list_member_added	Utilisateur qui ajoute	Utilisateur actuel	Liste
L’utilisateur retire quelqu’un d’une liste	list_member_removed	Utilisateur actuel	Utilisateur retiré	Liste
L’utilisateur est retiré d’une liste	list_member_removed	Utilisateur qui retire	Utilisateur actuel	Liste
L’utilisateur s’abonne à une liste	list_user_subscribed	Utilisateur actuel	Propriétaire de la liste	Liste
Un utilisateur s’abonne à la liste de l’utilisateur	list_user_subscribed	Utilisateur s’abonnant	Utilisateur actuel	Liste
L’utilisateur se désabonne d’une liste	list_user_unsubscribed	Utilisateur actuel	Propriétaire de la liste	Liste
Un utilisateur se désabonne de la liste de l’utilisateur	list_user_unsubscribed	Utilisateur se désabonnant	Utilisateur actuel	Liste
L’utilisateur met à jour son profil	user_update	Utilisateur actuel	Utilisateur actuel	Null
L’utilisateur met à jour son statut protégé	user_update	Utilisateur actuel	Utilisateur actuel	Null

Guide de migration des Messages privés

Le 17 septembre 2018, nous avons supprimé les anciens endpoints de Messages privés. Si vous utilisiez ces endpoints, veillez à migrer vers les nouveaux endpoints de Messages privés ou vers l’API Account Activity. Veuillez consulter cette annonce pour en savoir plus. Ce guide est conçu pour vous aider à migrer des anciennes API REST de Messages privés vers leurs remplaçantes améliorées, qui sont désormais hors version bêta. Vous trouverez ci-dessous un résumé des changements, une liste des nouvelles fonctionnalités, ainsi que les principales différences et points à prendre en compte pour faciliter la transition. Les nouveaux endpoints de Messages privés sont désormais disponibles pour tous les développeurs. Pour obtenir des conseils sur la migration depuis User Streams ou Site Streams, consultez le guide de migration vers l’API Account Activity.

Résumé des changements
Nouvelles fonctionnalités
Envoi de Messages privés
Réception de Messages privés
Suppression de Messages privés

Récapitulatif des modifications

Si vous utilisez encore les endpoints de DM suivants, vous devrez migrer vers les nouveaux endpoints.

Endpoint obsolète	Nouvel endpoint de migration
POST direct_messages/new	POST direct_messages/events/new
GET direct_messages/show	GET direct_messages/events/show
GET direct_messages	GET direct_messages/events/list
GET direct_messages/sent	GET direct_messages/events/list
POST direct_messages/destroy	DELETE direct_messages/events/destroy

Nouvelles fonctionnalités

Les nouveaux endpoints de l’API de Messages privés prennent en charge un certain nombre de nouvelles fonctionnalités et offrent un accès amélioré aux anciens Messages privés. Les nouvelles fonctionnalités incluent :

Prise en charge des pièces jointes multimédias (image, GIF et vidéo).
Possibilité d’inviter les utilisateurs à fournir des réponses structurées avec une liste d’options prédéfinies.
Jusqu’à 30 jours d’accès à l’historique des Messages privés.

Pour obtenir la liste complète des nouvelles fonctionnalités de Messages privés et des nouveaux endpoints d’API, consultez la documentation technique.

Différences et considérations de migration

Les nouveaux endpoints d’API se comportent de manière très différente par rapport à leurs précédents équivalents. Le simple fait de mettre à jour les URL des endpoints entraînera des erreurs dans votre application. Prenez en compte les points suivants lors de la mise à jour de votre application pour la migration.

Nouvel objet Direct Message

La première chose que vous remarquerez probablement est la nouvelle structure d’objet des Direct Messages. Cette nouvelle structure d’objet Message Create a été introduite pour prendre en charge de nouvelles fonctionnalités comme les Quick Replies et les Attachments. Le nouvel objet contient également un objet utilisateur plus compact. Votre application devra être mise à jour pour prendre en compte cette nouvelle structure d’objet lors de l’analyse et, éventuellement, au niveau des modèles de données ou du stockage. Pour la description de chaque propriété, consultez la documentation complète sur le Message Create Object. Exemple d’objet Message Create

{
      "type": "message_create",
      "id": "1234858592",
      "created_timestamp": "1392078023603",
      "initiated_via": {
        "tweet_id": "123456",
        "welcome_message_id": "456789"
      },
      "message_create": {
        "target": {
          "recipient_id": "1234858592"
        },
        "sender_id": "3805104374",
        "source_app_id": "268278",
        "message_data": {
          "text": "Blue Bird",
          "entities": {
            "hashtags": [],
            "symbols": [],
            "urls": [],
            "user_mentions": [],
          },
          "quick_reply_response": {
            "type": "options",
            "metadata": "external_id_2"
          },
          "attachment": {
            "type": "media",
            "media": {
             ...
            }
          }
        }
      }

Résumé

Structure d’objet Direct Message entièrement nouvelle.
Objet user simplifié.
Nouvelles informations disponibles (réponses Quick Reply, pièces jointes, etc.).

Envoi de messages privés

POST direct_messages/events/new remplace directement l’envoi de messages privés. La différence la plus importante avec cet endpoint est que toutes les informations sont désormais envoyées en JSON dans le corps de la requête POST, plutôt que sous forme de paramètres POST séparés. Exemple de requête Twurl

twurl -A 'Content-type: application/json' -X POST /1.1/direct\_messages/events/new.json -d '{"event": {"type": "message\_create", "message\_create": {"target": {"recipient\_id": "4534871"}, "message_data": {"text": "Hello World!"}}}}'

Notez dans la requête ci-dessus que le content-type est défini sur application/json plutôt que sur application/x-www-form-urlencoded. De plus, si vous générez la signature OAuth 1.0a, notez que le corps JSON n’est pas inclus dans le calcul de la signature. La plupart des bibliothèques OAuth prennent déjà cela en compte. Si vous utilisez twurl, assurez-vous d’utiliser au minimum la version 0.9.3.

Résumé

Le message est défini dans le corps de la requête POST, au format JSON
L’en-tête Content-Type doit être défini avec la valeur application/json
Le corps JSON n’est pas pris en compte lors de la génération de la signature OAuth.

Récupération des messages privés

La récupération des anciens messages privés se fait désormais via un seul endpoint d’API : GET direct_messages/events/list. La différence majeure avec ce nouvel endpoint est qu’il renvoie désormais à la fois les messages envoyés et reçus dans l’ordre chronologique inverse. Cela peut faciliter la reconstitution d’une conversation. Cependant, si vous ne cherchez que les messages envoyés ou que les messages reçus, vous devrez post-traiter la réponse en vous référant à la propriété sender_id. La pagination est désormais basée sur une valeur de curseur plutôt que sur l’identifiant d’un message privé. Une propriété cursor est renvoyée avec chaque réponse. GET direct_messages/events/list renverra jusqu’à 30 jours de messages passés, quel que soit le nombre de messages existant sur cette période. Lorsqu’aucun curseur n’est renvoyé, il n’y a plus d’autres messages à renvoyer. La méthode d’accès aux messages privés individuels avec GET direct_messages/events/show reste la même, même si l’objet de message privé renvoyé a une structure différente, comme décrit précédemment. Enfin, l’accès en temps réel aux messages privés se fait désormais via webhook avec l’Account Activity API. Pour obtenir des conseils sur la migration depuis User Streams ou Site Streams, consultez le guide de migration vers l’Account Activity API pour plus d’informations.

Récapitulatif

Les messages envoyés et reçus sont désormais renvoyés par le même endpoint.
Jusqu’à 30 jours de messages sont renvoyés.
Pagination basée sur des curseurs.
Accès en temps réel aux Messages privés (Direct Messages) via webhook.

Suppression des messages privés

Les messages privés peuvent désormais être supprimés à l’aide de DELETE direct_messages/events/destroy. L’interface reste en grande partie identique et requiert l’id du message à supprimer. La principale différence est que cet endpoint requiert désormais une requête DELETE au lieu d’une requête POST. La façon dont les messages privés supprimés apparaissent dans les clients officiels de X reste inchangée. Les messages privés ne sont supprimés que de l’interface de l’utilisateur correspondant au contexte fourni. Les autres membres de la conversation peuvent toujours accéder au message privé.

Résumé

La suppression d’un message privé nécessite l’id.
Le nouveau endpoint requiert une requête DELETE.
La manière dont les messages privés supprimés sont affichés dans les clients officiels X reste inchangée.

Des questions sur la migration vers les nouveaux endpoints de messages privés ? Posez votre question sur le forum de la communauté des développeurs sur devcommunity.com.

FAQ

Général

Quels sont les avantages d’utiliser l’Account Activity API ? L’Account Activity API utilise des webhooks, ce qui signifie qu’à la différence des API de streaming, nous n’avons pas besoin que vous mainteniez une connexion ouverte pour pouvoir vous envoyer des informations. Les webhooks sont également différents des API REST, car vous n’avez pas à nous interroger des centaines de fois toutes les 15 minutes pour obtenir les données qui vous intéressent. Cela améliore l’efficacité entre un utilisateur et votre App, car les données sont livrées au moment où elles se produisent. L’Account Activity API présente plusieurs avantages :

Vitesse : nous livrons les données à la vitesse de X.
Simplicité : nous livrons tous les événements d’un compte via une seule connexion webhook. Les activités diffusées via l’API incluent les Publications, les @mentions, les réponses, les Retweets, les Tweets cités, les Retweets de Tweets cités, les favoris, les Messages privés envoyés, les Messages privés reçus, les abonnements, les blocages et les masquages.
Évolutivité : vous recevez toutes les activités pour un compte que vous gérez sans être limité par des limites de taux ni des plafonds d’événements.

L’Account Activity API est disponible en offres Premium sandbox, Premium payante et Enterprise, ce qui vous permet de monter en charge si vous avez besoin de gérer davantage de comptes pour des fonctionnalités de conformité ou des fonctionnalités supplémentaires. Pour commencer, téléchargez des extraits de code d’exemple depuis GitHub. Comment déterminer quel niveau de produit est le mieux adapté pour moi ? Veuillez consulter notre page Account Activity API Overview pour en savoir plus sur les différences entre les options Premium et l’option Enterprise. Quelle est la différence entre un environnement Premium et un webhook Enterprise ? Il n’y a aucune différence. Chaque environnement Premium aura son propre webhook_id. J’ai besoin d’environnements de développement, de préproduction et de production pour l’Account Activity API, est‑ce possible ? Oui ! Avec les niveaux payants de l’Account Activity API (Premium payant et Enterprise), il est possible d’enregistrer plusieurs URL de webhook et de gérer séparément les abonnements pour chacune via les méthodes de l’API. De plus, plusieurs apps clientes peuvent être ajoutées à une liste d’autorisation afin de maintenir l’autorisation pour vos utilisateurs actuellement autorisés. Avez-vous des guides étape par étape pour la mise en place de l’Account Activity API ? En effet, nous en avons !

Si vous débutez, nous vous recommandons de consulter notre guide Getting started with webhooks
Suivez nos scripts pris en charge par X Dev :
- Account Activity API dashboard, une application web Node qui affiche les événements webhook.
- Le chatbot SnowBot, une application web Ruby construite sur les Account Activity et Direct Message APIs. Cette base de code inclut un script pour aider à configurer les webhooks de l’Account Activity API.

Existe‑t‑il un moyen de récupérer les données si notre système est indisponible pendant un certain temps ? Avec les niveaux payants de l’Account Activity API (Premium payant et Enterprise), notre système va réessayer de vous envoyer les activités plusieurs fois sur une période de quatre heures. Si votre système ne répond pas dans ce délai de quatre heures, l’activité sera perdue et vous devrez utiliser d’autres endpoints REST pour récupérer les données dans un délai de 7 jours. Nous vous suggérons d’utiliser vos différents webhooks, ou environnements, comme outils de redondance, comme l’Account Activity Replay API, afin de vous assurer que vous ne manquiez aucune activité si l’un de vos systèmes tombe en panne. Quelle méthode d’authentification dois‑je utiliser avec l’Account Activity API ? Les méthodes d’autorisation requises pour l’Account Activity API sont décrites, méthode par méthode, dans les pages de Référence de l’API. Si vous commencez tout juste avec l’authentification X, nous vous recommandons de lire cette section. Qu’est‑ce qu’un challenge-response check (CRC) ? La vérification de la réponse au défi (challenge response check) de l’Account Activity API est une fonctionnalité de sécurité mise en place pour garantir que les activités de l’Account Activity API sont envoyées au bon développeur. Elle peut également être utilisée par les développeurs pour vérifier que les données qu’ils reçoivent proviennent de X. X enverra automatiquement un CRC à votre URL de webhook toutes les 24 heures, à partir du dernier moment où l’URL du webhook a été validée. Votre système doit répondre avec une réponse valide en moins de 3 secondes pour rester validé. Veuillez consulter notre page Securing webhooks pour plus de détails. Y a-t-il quelque chose qui invaliderait immédiatement mon URL de webhook ? Si l’un des événements suivants se produit, nous marquerons immédiatement votre webhook comme invalide :

Le serveur répond à un CRC avec un jeton incorrect. Dans ce cas, notre système ne réessaiera pas de vous envoyer l’activité.
L’URL du webhook a un certificat incorrect configuré. Dans ce cas, notre système ne réessaiera pas de vous envoyer l’activité.
Votre serveur renvoie un code de réponse qui n’est ni 2XX, ni 4XXX, ni 5XXX.
Vous indiquez l’utilisation de gzip sans réellement l’envoyer.
Vous n’indiquez pas l’utilisation de gzip, mais vous l’envoyez effectivement dans la réponse.

Vais-je recevoir des activités en double si je suis abonné à des utilisateurs qui interagissent entre eux ? Oui. Si votre application web a des abonnements actifs pour l’Utilisateur A et l’Utilisateur B, et que l’Utilisateur A mentionne l’Utilisateur B dans une Publication, deux activités POST seront envoyées au webhook enregistré. Chaque activité comportera un indicateur “for_user_id” pour indiquer à quel abonnement l’activité appartient. **Lorsque je crée un abonnement vers mon webhook, puis-je remplacer la partie /all/ de l’endpoint suivant par d’autres objets de données d’Account Activity pour limiter les activités livrées par l’API ? **POST https://api.x.com/1.1/account_activity/all/:env_name/subscriptions.json Non, ce n’est pas possible. À l’heure actuelle, nous n’avons que le produit /all/ disponible. **Existe-t-il un moyen d’utiliser l’Account Activity API sans demander les autorisations Direct Messages aux utilisateurs ? ** À ce stade, les autorisations Direct Messages sont nécessaires, car il n’existe aucun moyen de « filtrer » les activités Direct Messages pour cette API. Existe-t-il une version sandbox de l’Account Activity API ? Oui, nous proposons une option sandbox pour les tests. Notre option sandbox est limitée à un seul webhook avec une limite de 15 abonnements maximum. Vous pouvez en savoir plus sur l’option sandbox dans notre documentation. **Est-il possible d’utiliser l’Account Activity API pour obtenir les Retweets de Publications qui mentionnent des utilisateurs abonnés ? ** Malheureusement, cela ne fait pas partie des activités livrées avec cette API. Pour cela, nous vous suggérons d’utiliser plutôt la Streaming API. Quels sont les types d’activité possibles représentés par un tweet_create_event ? Un payload tweet_create_event sera envoyé : Si l’utilisateur abonné effectue l’une des actions suivantes :

Crée une Publication
Fait un Retweet
Répond à une Publication

Si un autre utilisateur :

@mentionne* l’utilisateur abonné
Cite un Tweet créé par l’utilisateur abonné

Remarque : l’Account Activity API ne livre des événements que lorsque l’utilisateur abonné recevrait une notification de X et pourrait voir l’événement publiquement. Cela signifie que, si le compte mentionné (@userA) suit le compte protégé (@userB), alors UserA recevra une notification indiquant que UserB l’a mentionné. Si UserA ne suit pas UserB (et n’a pas été approuvé par UserB), UserA ne recevra pas de notification, et par conséquent, un tweet_create_event ne serait pas envoyé via AAA si @userA avait un abonnement. Si un utilisateur bloqué mentionne mon utilisateur abonné, comment puis-je l’identifier ? Vous verrez un champ booléen user_has_blocked au niveau supérieur de la réponse JSON, défini sur « true » ou « false ». Ce champ ne sera exposé que pour les mentions de Publication. Enterprise Comment puis-je ajouter mon app à une allowlist ou vérifier si mon app est déjà sur l’allowlist ? Pour gérer les X apps que vous avez ajoutées à une liste d’autorisation pour l’accès via les Enterprise APIs, veuillez contacter votre responsable de compte en lui fournissant l’id de votre application. Vous pouvez trouver l’id de votre application en accédant à la page “Apps” dans la Console de développement. Si j’ai accès à trois webhooks, puis-je utiliser trois webhooks pour chacune des applications que j’ai enregistrées pour un usage Enterprise ? La limite de webhooks est définie au niveau du compte, et non au niveau de l’application. Si vous avez accès à trois webhooks et à deux applications enregistrées pour un usage Enterprise, vous pouvez utiliser deux webhooks sur une application et le troisième sur l’autre, mais pas trois sur chaque application. Puis-je spécifier quels types d’événements seront renvoyés à l’aide de l’Account Activity Replay API ? Les types d’événements à rejouer ne peuvent pas être spécifiés. Tous les événements transmis pendant la fenêtre de dates et d’heures spécifiée seront rejoués. Y aura-t-il de nouvelles tentatives si mon application ne parvient pas à ingérer un événement de l’Account Activity Replay API ? Non, il n’y aura pas de nouvelles tentatives. Si une application ne parvient pas à ingérer un événement envoyé par l’Account Activity Replay API, un autre job Replay peut être soumis pour la même période afin de tenter une nouvelle livraison de tous les événements Replay manqués. Que dois-je faire lorsque je reçois un événement de fin de traitement indiquant un succès partiel ? Nous vous suggérons de relever les horodatages des événements reçus et de demander un autre job Replay pour les événements qui ont été manqués. Combien de jobs Account Activity Replay API puis-je faire tourner en même temps ? Un seul job Account Activity Replay API par webhook peut être en cours d’exécution à la fois. Comment puis-je différencier les événements Account Activity Replay API des événements de production en temps réel lorsqu’ils sont livrés à mon webhook ? Étant donné que l’Account Activity Replay API livre toujours des événements passés, les événements peuvent être différenciés des événements de production en temps réel en se basant sur l’horodatage de l’événement. Combien de temps après puis-je commencer à utiliser l’Account Activity Replay API pour renvoyer une activité que mon application a abandonnée ou manquée ? Une activité devient disponible pour une nouvelle livraison environ 10 minutes après sa création.

Guide de résolution des erreurs

Code 32

Cette erreur signifie généralement qu’un élément est mal formé dans la requête, les en-têtes, les informations d’autorisation ou l’URL que vous spécifiez. Ce n’est pas une erreur de l’Account Activity API, c’est une erreur d’autorisation et X ne reçoit pas la configuration OAuth ou l’URL appropriée.

Enterprise - Assurez-vous que les consumer keys et les access tokens que vous utilisez appartiennent à une App X qui a été enregistrée pour l’utilisation des produits Enterprise. Si vous ne disposez pas de vos consumer keys et access tokens, ou si vous devez ajouter votre App X à la liste d’autorisation (allowlist), veuillez contacter votre responsable de compte.
Si vous vous authentifiez avec un contexte utilisateur, assurez-vous d’avoir correctement autorisé votre requête avec les oauth nonce, oauth_signature et oauth_timestamp appropriés.
Assurez-vous que vos access tokens ont le niveau d’autorisation approprié.
- Dans l’onglet « Keys and tokens » du app dashboard, veuillez vérifier que vos access tokens ont le niveau d’autorisation « Read, write, and direct messages » (permission level).
- Si le niveau d’autorisation des tokens est défini sur une valeur inférieure, accédez à l’onglet « Permissions », ajustez l’autorisation d’accès sur « Read, write, and direct messages », puis régénérez vos access tokens et secrets depuis l’onglet « Keys and tokens ».
Assurez-vous que votre URL est correctement formée.
- Veuillez garder à l’esprit que :env_name est sensible à la casse.

Code 200 - Interdit

Premium - Assurez-vous de disposer d’un compte développeur approuvé avant d’essayer d’effectuer une requête vers l’API. Vous devez également utiliser la valeur :env_name appropriée dans la requête, que vous pouvez configurer sur la page dev environments.
Enterprise - Assurez-vous que votre gestionnaire de compte vous a bien accordé l’accès à l’Account Activity API.
Assurez-vous d’avoir correctement configuré votre URI. Cette erreur peut se produire si vous avez saisi un URI incorrect dans votre requête.

Code 214 - L’URL du webhook ne respecte pas les exigences.

Assurez-vous d’utiliser HTTPS.
L’URL de votre webhook est peut-être mal formée.
Pour en savoir plus sur la configuration de votre URL de webhook, consultez la section Develop webhook consumer app sur la page Getting started with webhooks.

Code 214 - Latence élevée lors de la requête CRC GET. Votre webhook doit répondre en moins de 3 secondes.

Cela signifie que votre serveur est lent. Assurez-vous que vous répondez au CRC en moins de 3 secondes.

Code 214 - Code de réponse différent de 200 lors d’une requête CRC GET (p. ex. 404, 500, etc).

Votre serveur est en panne. Assurez-vous qu’il fonctionne correctement.

Code 214 - Trop de ressources déjà créées.

Enterprise - Vous avez déjà utilisé tous vos webhooks. Utilisez l’endpoint GET webhooks avec chacune de vos applications enregistrées pour identifier où sont distribués vos webhooks.

Code 261 - L’App ne peut pas effectuer d’opérations d’écriture.

L’App que vous utilisez avec l’API n’a pas le niveau d’autorisation approprié défini pour son jeton d’accès (access token) et son secret de jeton d’accès (access token secret). Accédez à l’onglet ‘Keys and tokens’ sur le tableau de bord X apps et vérifiez les niveaux d’autorisation attribués à votre jeton d’accès et à son secret. S’il est défini sur autre chose que ‘Read, write and Direct Messages’, vous devrez alors ajuster les paramètres dans l’onglet ‘Permission’ et régénérer votre jeton d’accès et son secret pour appliquer les nouveaux paramètres.
Autre possibilité : vous tentez d’enregistrer un webhook en utilisant l’authentification App-only, ce qui n’est pas pris en charge. Authentifiez-vous plutôt avec un contexte utilisateur, comme indiqué dans les sections de la Référence de l’API pour l’enregistrement d’un webhook pour Enterprise Account Activity API.

Index de la Référence de l’API Account Activity


Purpose	Enterprise
Enregistre une URL de webhook / Génère un webhook_id	POST webhooks
Renvoie toutes les URL de webhook et leurs statuts	GET webhooks
Déclenche manuellement une vérification de la réponse au challenge	PUT webhooks/:webhook_id
Abonne une application aux événements d’un compte	POST webhooks/:webhook_id/subscriptions/all
Renvoie le nombre d’abonnements actuellement actifs	GET subscriptions/count
Vérifie si un webhook est abonné à un compte	GET webhooks/:webhook_id/subscriptions/all
Renvoie la liste des abonnements actuellement actifs	GET webhooks/:webhook_id/subscriptions/all/list
Supprime le webhook	DELETE webhooks/:webhook_id
Désactive un abonnement à l’aide d’OAuth à 3 étapes (OBSOLÈTE)	DELETE webhooks/:webhook_id/subscriptions/all
Désactive un abonnement à l’aide d’OAuth en mode application uniquement	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json
Rédélivre les activités à un webhook	POST replay/webhooks/:webhook_id/subscriptions/all

API Account Activity entreprise

POST account_activity/webhooks

Enregistre une nouvelle URL de webhook pour le contexte d’application donné. L’URL sera validée via une requête CRC avant d’être enregistrée. Si la validation échoue, un message d’erreur détaillé est renvoyé au demandeur. Le nombre de webhooks autorisés est déterminé par le forfait de facturation.

URL de la ressource

https://api.x.com/1.1/account_activity/webhooks.json

Informations sur la ressource


Format de réponse	JSON
Authentification requise	Oui (contexte utilisateur – tous les consumer et access tokens)
Limité par le taux de requêtes	Oui
Requêtes / fenêtre de 15 minutes (authentification utilisateur)	15
Prise en charge des modifications de Tweet	Tous les objets Tweet incluront des métadonnées de modification de Tweet décrivant l’historique des modifications du Tweet. Consultez la page « Principes de base des Tweet edits » pour plus de détails.

Paramètres


url (obligatoire)	URL encodée du point de terminaison de rappel.

Exemple de requête

$ curl —request POST —url ‘https://api.x.com/1.1/account_activity/webhooks.json?url=https%3A%2F%2Fyour_domain.com%2Fwebhooks%2Ftwitter%2F0' —header ‘authorization: OAuth oauth_consumer_key=“CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“ACCESS_TOKEN”, oauth_version=“1.0“‘

Réponses HTTP

Code HTTP	Message
200	L’URL de webhook est enregistrée pour l’application indiquée
403	Votre requête contient une erreur. Consultez la section des messages d’erreur ci-dessous.

Exemple de réponse - réussite

_HTTP 200_

    {
      "id": "1234567890",
      "url": "https://your_domain.com/webhook/twitter/0",
      "valid": true,
      "created_at": "2016-06-02T23:54:02Z"
    }

Messages d’erreur

Code	Message
214	L’URL du webhook ne respecte pas les exigences.
214	Trop de ressources ont déjà été créées.
214	L’URL du webhook ne respecte pas les exigences. Jeton CRC invalide ou format de réponse JSON invalide.
214	Latence élevée sur la requête CRC GET. Votre webhook doit répondre en moins de 3 secondes.
214	Code de réponse différent de 200 lors de la requête CRC GET (par exemple 404, 500, etc.).

HTTP 403

    {
      "errors": [
        {
          "code": 214,
          "message": "Too many resources already created."
        }
      ]
    }

GET account_activity/webhooks

Renvoie toutes les URL et leurs statuts pour l’application donnée. Une URL est marquée comme invalide si elle échoue au contrôle de validation quotidien. Pour réactiver l’URL, appelez le point de terminaison de mise à jour.

URL de ressource

https://api.x.com/1.1/account_activity/webhooks.json

Informations sur la ressource


Format de réponse	JSON
Authentification requise	Oui (App uniquement - Jeton Bearer)
Limitation de débit	Oui
Requêtes / fenêtre de 15 min (authentification de l’App)	15

Exemple de requête

    $ curl --request GET
     --url https://api.x.com/1.1/account_activity/webhooks.json
     --header 'authorization: Bearer TOKEN'

Exemple de réponse

HTTP 200 OK

    [
      {
        "id": "1234567890",
        "url": "https://your_domain.com/webhook/twitter/0",
        "valid": true,
        "created_at": "2016-06-02T23:54:02Z"
      }
      {
        "id": "2468013579",
        "url": "https://your_domain2.com/webhook/twitter/0",
        "valid": true,
        "created_at": "2016-06-04T22:31:29Z"
      }
    ]

Messages d’erreur

Code	Message
99	Vous n’avez pas accès à cette ressource.

PUT account_activity/webhooks/:webhook_id

Déclenche la vérification de réponse au défi (CRC) pour l’URL du webhook spécifié. Si la vérification réussit, renvoie un 204 et réactive le webhook en définissant son statut sur valid.

URL de la ressource

https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json

Informations sur la ressource


Format de réponse	JSON
Nécessite une authentification	Oui (contexte utilisateur - tous les tokens de consommateur et d’accès)
Limité en débit	Oui
Requêtes / fenêtre de 15 minutes (authentification utilisateur)	15

Paramètres


webhook_id (obligatoire)	ID de webhook. Défini dans le chemin de la ressource.

Exemple de requête

    $ curl --request PUT
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
     --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'

Réponse

HTTP 204 OK

{ }

Messages d’erreur

Code	Message
34	Le webhook n’existe pas ou est associé à une autre application X.
214	L’URL du webhook ne respecte pas les exigences.
214	L’URL du webhook ne respecte pas les exigences. Jeton CRC invalide ou format de réponse JSON non valide.
214	Latence élevée sur la requête CRC GET. Votre webhook doit répondre en moins de 3 secondes.
214	Code de réponse différent de 200 lors de la requête CRC GET (p. ex. 404, 500, etc.).

POST account_activity/webhooks/:webhook_id/subscriptions/all

Abonne l’application fournie à tous les événements, pour tous les types de messages, dans le contexte de l’utilisateur indiqué. Après l’activation, tous les événements pour l’utilisateur ayant émis la requête seront envoyés au webhook de l’application via une requête POST. Les abonnements sont actuellement limités en fonction de la configuration de votre compte. Si vous avez besoin d’ajouter davantage d’abonnements, veuillez contacter votre chargé de compte.

URL de la ressource

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

Informations sur la ressource


Format de la réponse	JSON
Authentification requise	Oui (OAuth à 3 volets - clé consommateur autorisée et jeton d’accès de l’utilisateur abonné)
Limitation de débit	Oui
Requêtes / fenêtre de 15 min (authentification utilisateur)	500

Paramètres


webhook_id (obligatoire)	Identifiant du webhook. Défini dans le chemin de la ressource.

Exemple de requête

    $ curl --request POST
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
     --header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBING_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

Exemple de réponse - succès

HTTP 204 NO CONTENT

{}

Messages d’erreur

Code	Message
34	Le webhook n’existe pas ou est associé à une autre application X.
348	L’application cliente n’est pas autorisée à accéder aux abonnements webhook de cet utilisateur.

GET account_activity/subscriptions/count

Renvoie le nombre d’abonnements actuellement actifs sur votre compte. Notez que le endpoint /count nécessite l’authentification OAuth en mode application seule (application-only OAuth) ; vous devez donc effectuer vos requêtes à l’aide d’un jeton Bearer plutôt qu’avec un contexte utilisateur.

URL de la ressource

https://api.x.com/1.1/account_activity/subscriptions/count.json

Informations sur la ressource


Format de la réponse	Code de statut HTTP
Nécessite une authentification	Oui (application uniquement - Jeton Bearer)
Soumis à une limite de débit	Oui
Requêtes / fenêtre de 15 minutes (authentification d’application)	15

Codes de réponse HTTP


Code	Message
200	Succès. Le nombre d’abonnements pour le webhook demandé sera renvoyé.
401	Votre App ne dispose pas des autorisations nécessaires pour consulter les abonnements du webhook spécifié.

Exemple de requête

    $ curl --request GET
     --url https://api.x.com/1.1/account_activity/subscriptions/count.json
     --header 'authorization: Bearer TOKEN'

Exemple de réponse - Succès

HTTP 200

    {
      "account_name":"my-account",
      "subscriptions_count_all":"1",
      "subscriptions_count_direct_messages":"0",
      "provisioned_count":"50"
    }

Messages d’erreur

Code	Message
32	Impossible de vous authentifier.

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "Could not authenticate you."
        }
      ]
    }

GET account_activity/webhooks/:webhook_id/subscriptions/all

Permet de déterminer si une configuration de webhook est abonnée aux événements de l’utilisateur fourni. Si le contexte utilisateur fourni dispose d’un abonnement actif avec l’App fournie, la requête renvoie 204 OK. Si le code de réponse n’est pas 204, alors l’utilisateur n’a pas d’abonnement actif. Voir ci‑dessous le code de réponse HTTP et les messages d’erreur pour plus de détails.

URL de la ressource

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

Informations sur la ressource


Format de réponse	JSON
Authentification requise	Oui (OAuth à 3 volets – clé consumer autorisée et jeton d’accès de l’utilisateur abonné)
Soumis à une limite de débit	Oui
Requêtes / fenêtre de 15 minutes (authentification utilisateur)	500

Paramètres


webhook_id (obligatoire)	Identifiant du webhook. Défini dans le chemin de la ressource.

Exemple de requête

$ curl —request GET —url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json —header ‘authorization: OAuth oauth_consumer_key=“WHITELISTED_CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“SUBSCRIBING_USER’S_ACCESS_TOKEN”, oauth_version=“1.0“‘

Exemple de réponse - Succès

HTTP 204 NO CONTENT

{ }

GET account_activity/webhooks/:webhook_id/subscriptions/all/list

Retourne une liste des abonnements actuels de type All Activity pour le webhook spécifié. Notez que le point de terminaison /list nécessite OAuth en mode application uniquement, les requêtes doivent donc être effectuées au moyen d’un jeton Bearer plutôt que dans un contexte utilisateur.

URL de la ressource

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json

Informations sur la ressource


Format de réponse	Code de réponse HTTP
Nécessite une authentification	Oui (App uniquement - jeton Bearer)
Soumis à une limite de débit	Oui
Requêtes / fenêtre de 15 min (authentification de l’App)	50

Paramètres


webhook_id (required)	ID du webhook. Défini dans le chemin de la ressource.

Codes de réponse HTTP

Code	Message
200	Succès. Une liste d’abonnements pour le webhook demandé sera renvoyée.
401	Votre application n’est pas autorisée à consulter les abonnements pour le webhook spécifié.

Exemple de requête

$ curl —request GET —url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all/list.json —header ‘authorization: Bearer TOKEN’

Exemple de réponse - Succès

HTTP 200

    {
      "webhook_id": "1234567890",
      "webhook_url": "https://your_domain.com/webhook/twitter/0",
      "application_id": "11231812",
      "subscriptions": [{
        "user_id": "20212306"
      }]
    }

Messages d’erreur

Code	Message
32	Impossible de vous authentifier.

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "Could not authenticate you."
        }
      ]
    }

DELETE account_activity/webhooks/:webhook_id

Supprime le webhook de la configuration de l’application fournie. L’ID du webhook est accessible en effectuant un appel à GET /1.1/account_activity/webhooks.

URL de la ressource

https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json

Informations sur la ressource


Format de réponse	JSON
Nécessite une authentification	Oui (contexte utilisateur – tous les jetons consumer et d’accès)
Soumis à une limitation de débit	Oui
Requêtes / fenêtre de 15 min (authentification utilisateur)	15

Paramètres


webhook_id (required)	Identifiant du webhook. Défini dans le chemin de la ressource.

Exemple de requête

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
     --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'

Réponse

HTTP 204 OK

{ }

DELETE account_activity/webhooks/:webhook_id/subscriptions/all (OBSOLÈTE)

Désactive le ou les abonnements pour le contexte utilisateur et l’application fournis. Après la désactivation, aucun événement concernant l’utilisateur à l’origine de la requête ne sera envoyé à l’URL du webhook.

URL de la ressource

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

Informations sur la ressource


Format de réponse	JSON
Nécessite une authentification	Oui (OAuth à 3 voies - clé consommateur autorisée et jeton d’accès de l’utilisateur abonné)
Soumis à une limitation de débit	Oui
Requêtes / fenêtre de 15 minutes (authentification utilisateur)	500

Paramètres


webhook_id (requis)	ID du webhook. Définie dans le chemin de la ressource.

Exemple de requête

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
     --header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

Exemple de requête

{ }

DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json

Désactive l’abonnement pour le webhook et l’id utilisateur spécifiés. Après la désactivation, tous les événements pour l’utilisateur à l’origine de la requête ne seront plus envoyés à l’URL du webhook. Notez que cet endpoint requiert OAuth en mode application uniquement ; les requêtes doivent donc être effectuées à l’aide d’un jeton Bearer plutôt qu’avec un contexte utilisateur.

URL de la ressource

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json

Informations sur la ressource


Format de réponse	JSON
Authentification requise	Oui (application uniquement - Jeton Bearer)
Limitation de débit	Oui
Requêtes / fenêtre de 15 minutes	500

Exemple de requête

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
     --header 'authorization: Bearer TOKEN'

Réponse

HTTP 204 NO CONTENT

Messages d’erreur

Code	Message
404	Désolé, cette page n’existe pas. - Cela se produit souvent lorsque l’id utilisateur spécifié n’est en fait pas abonné.

Replay API

POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json ¶ Envoie une requête pour récupérer les activités des cinq derniers jours au maximum pour toutes les souscriptions présentes pendant les fenêtres de dates et d’heures spécifiées dans la requête. Si votre webhook possède des souscriptions utilisateur actives, vous recevrez également ces événements en parallèle. Remarque : nous effectuons un CRC avant de livrer les événements de replay.


Méthode de requête	HTTP POST
URL	/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm
Format de réponse	JSON
Nécessite une authentification	Oui (application uniquement – Jeton Bearer)
Limite de débit	5 requêtes par tranche de 15 minutes. Il n’y a actuellement aucun maximum sur le nombre de jobs de replay qui peuvent être demandés.
from_date	L’horodatage UTC le plus ancien (de début) à partir duquel les événements seront fournis, qui doit être au format ‘yyyymmddhhmm’. L’horodatage a une granularité à la minute et est inclusif (par exemple, 12:00 inclut la minute 00). Les heures valides doivent se situer dans les 5 derniers jours, en heure UTC, et pas plus récentes que 31 minutes avant le moment actuel. Il est recommandé que from_date et to_date soient espacés d’environ 2 heures au maximum.
to_date	L’horodatage UTC le plus récent (de fin) jusqu’auquel les événements seront fournis, qui doit être au format ‘yyyymmddhhmm’. L’horodatage a une granularité à la minute et est exclusif (par exemple, 12:30 n’inclut pas la 30e minute de l’heure). Les heures valides doivent se situer dans les 5 derniers jours, en heure UTC, et pas plus récentes que 10 minutes avant le moment actuel.

Réponses

Les réponses suivantes peuvent être renvoyées par l’API. 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. Pour les réponses dont le statut est différent de 200, vous devez corriger l’erreur puis réessayer.

Status	Texte	Code d’erreur	Description	Message
202	Accepted	N/A	La requête a réussi et les activités seront envoyées.	N/A
400	Bad Request	214	Le webhook a été marqué comme invalide.	Le webhook est marqué comme invalide et nécessite une vérification CRC.
400	Bad Request	357	Le paramètre de requête est manquant.	: queryParam est requis.
400	Bad Request	358	Le paramètre de route ou de requête est mal formé.	Impossible d’analyser le paramètre.
400	Bad Request	360	Le paramètre de route est négatif.	webhook_id: [] n’est pas supérieur ou égal à 0.
400	Bad Request	368	from_date ou to_date n’est pas dans le passé.	: [<field_value>] n’est pas dans le passé.
400	Bad Request	356	from_date doit être antérieur à to_date.	from_date doit être antérieur à to_date.
400	Bad Request	356	from_date doit être dans les 5 derniers jours.	from_date doit être dans les 5 derniers jours.
401	Unauthorized	32	L’authentification HTTP a échoué en raison de l’authentification 3-legged fournie.	Méthode d’authentification invalide. Veuillez utiliser l’authentification application-only.
401	Unauthorized	61	Le client n’est pas autorisé à appeler cette méthode.	Le client n’est pas autorisé à appeler cette méthode.
403	Forbidden	200	Le client ne dispose pas d’un compte entreprise avec Replay activé.	Un compte entreprise de l’Account Activity API avec Replay activé est requis. Veuillez confirmer que vous disposez d’un compte entreprise et que Replay est activé.
404	Not Found	34	webhook_id inexistant ; incompatibilité webhook_id-application_id.	Le webhook n’existe pas ou est associé à une autre application X.
409	Conflict	355	Une requête est en cours et doit terminer son traitement avant d’en lancer une autre.	Un job de replay est déjà en cours pour ce webhook.
429	Too Many Requests	88	Limite de débit atteinte (limite du nombre de requêtes par période de temps).	Trop de requêtes. Veuillez réduire la fréquence de vos requêtes API.
500	Internal Server Error	0	Erreur interne du serveur.	Erreur interne du serveur.
503	Service Unavailable	67	Un ou plusieurs services dont dépend X sont indisponibles.	Erreur de serveur X. Réessayez en utilisant une stratégie de backoff exponentiel.

Message “Job completed successfully”

Une fois que votre tâche est terminée avec succès, l’API Account Activity Replay enverra l’événement de fin de tâche suivant. Une fois que vous aurez reçu cet événement, la tâche sera terminée et vous pourrez en soumettre une autre.

{
  "replay\_job\_status": {
    "webhook_id": "1234577122340233217",
    "job_state": "Complete",
    "job\_state\_description": "Job completed successfully"
    "job_id": "1095098195724558337"
  }
}

Message « Job failed to complete »

En cas d’échec de votre job, nous renverrons le message suivant pour vous inviter à relancer votre job Replay. Une fois cet événement reçu, le job a terminé son exécution et vous pouvez en soumettre un autre.

{
  "replay\_job\_status": {
    "webhook_id": "123451374207332352",
    "job_state": "Incomplete",
    "job\_state\_description": "Job failed to deliver all events, please retry your replay job",
    "job_id": "1093226942650736640"
  }
}

Exemple de requête curl

    curl --request POST  --url 'https://api.x.com/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm'
    --header 'authorization: Bearer TOKEN'

Exemple de réponse

HTTP 202

{
  "job_id": "1234567890",
  "created_at": "2016-06-02T23:54:02Z"
}