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. 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) |
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 ?
-
Explorez nos exemples de code :
Gérer les webhooks et les utilisateurs abonnés
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 :
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"'
Une visite guidée vidéo de l’Account Activity API
- 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 ?
-
Explorez notre code d’exemple :
Enterprise
Premiers pas avec les webhooks
- 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
3. Développer une application consommatrice de webhooks
-
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.
-
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 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
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 :
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 :
{
"response_token": "sha256=x0mYd8hz2goCTfcNAaMqENy2BFgJJfJOb4PdvTffpwg="
}
- 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).
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&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
Blocs réseau agrégés de X
-
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
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 ?
Ajout et suppression d’abonnements utilisateur
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 |
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.
| | | |
|---|
| 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 | | ✓ |
- 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.
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 (*).
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. 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.
| | | |
|---|
| 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 | | ✓ |
- 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.
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 (*).
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. 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.
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
|
|---|
| 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. |
| 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é. |
{
"for_user_id": "2244994945",
"tweet_create_events": [
{
<Tweet Object>
}
]
}
{
"for_user_id": "2244994945",
"user_has_blocked": "false",
"tweet_create_events": [
{
<Tweet Object>
}
]
}
{
"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>
}
}]
}
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "follow",
"created_timestamp": "1517588749178",
"target": {
<User Object >
},
"source": {
< User Object >
}
]
}
}
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "unfollow",
"created_timestamp": "1517588749178",
"target": {
<User Object >
},
"source": {
< User Object >
}
]
}
}
{
"for_user_id": "2244994945",
"block_events": [{
"type": "block",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}]
}
{
"for_user_id": "2244994945",
"block_events": [{
"type": "unblock",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}]
}
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "mute",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}
]
}
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "unmute",
"created_timestamp": "1518127020304",
"source": {
<User Object>
},
"target": {
<User Object>
}
}
]
}
{
"user_event": {
"revoke": {
"date_time": "2018-05-24T09:48:12+00:00",
"target": {
"app_id": "13090192"
},
"source": {
"user_id": "63046977"
}
}
}
}
{
"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"
}
}
}
{
"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
Disponibilité des données et types
Introduction à la migration
- 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 :
Pour vous aider à effectuer une migration en douceur vers ces nouveaux endpoints et services, nous proposons deux guides de migration :
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
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.
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)
Enterprise Account Activity API - Toutes les activités
Différences et considérations de migration
Nouvelles fonctionnalités
Gestion des abonnements utilisateur
Suivez les étapes ci-dessous pour migrer facilement de l’API Site Streams vers l’API Account Activity
- 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)
Le tableau de bord Account Activity (exemple d’application pour l’API Account Activity)
- 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
| 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
Récapitulatif des modifications
Nouvelles fonctionnalités
- 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
Nouvel objet Direct Message
{
"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.).
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!"}}}}'
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
- 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
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.
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
-
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.
-
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.
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.
- 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
https://api.x.com/1.1/account_activity/webhooks.json
| |
|---|
| 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. |
| |
|---|
| url (obligatoire) | URL encodée du point de terminaison de rappel. |
| 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"
}
| 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.). |
{
"errors": [
{
"code": 214,
"message": "Too many resources already created."
}
]
}
GET account_activity/webhooks
URL de ressource
https://api.x.com/1.1/account_activity/webhooks.json
| |
|---|
| 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'
[
{
"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
valid.
URL de la ressource
https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json
| |
|---|
| 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 |
| |
|---|
| webhook_id (obligatoire) | ID de webhook. Défini dans le chemin de la ressource. |
$ 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"'
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
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| 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 |
| |
|---|
| webhook_id (obligatoire) | Identifiant du webhook. Défini dans le chemin de la ressource. |
$ 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
| 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
/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.
https://api.x.com/1.1/account_activity/subscriptions/count.json
| |
|---|
| 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 |
| |
|---|
| 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. |
{
"errors": [
{
"code": 32,
"message": "Could not authenticate you."
}
]
}
GET account_activity/webhooks/:webhook_id/subscriptions/all
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| 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
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json
| |
|---|
| 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"
}]
}
| Code | Message |
|---|
| 32 | Impossible de vous authentifier. |
{
"errors": [
{
"code": 32,
"message": "Could not authenticate you."
}
]
}
DELETE account_activity/webhooks/:webhook_id
https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json
| |
|---|
| 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 |
| |
|---|
| 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"'
DELETE account_activity/webhooks/:webhook_id/subscriptions/all (OBSOLÈTE)
URL de la ressource
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| 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"'
DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
URL de la ressource
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
| |
|---|
| 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 |
$ 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é. |
| |
|---|
| 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. |
| 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”
{
"replay\_job\_status": {
"webhook_id": "1234577122340233217",
"job_state": "Complete",
"job\_state\_description": "Job completed successfully"
"job_id": "1095098195724558337"
}
}
Message « Job failed to complete »
{
"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"
}
}
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"
}
