Cet endpoint a été mis à jour pour inclure les metadata d’édition de Post. Pour en savoir plus, consultez la page des fondamentaux “Modifier des Posts”. Cet endpoint est souvent utilisé avec les endpoints de Messages privés. Nous avons lancé de nouveaux endpoints de Messages privés v2. Notez que les Account Activity API 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 en temps réel aux activités liées à un compte utilisateur via des webhooks. Vous pouvez ainsi recevoir en temps réel des Posts, des Messages privés et d’autres événements de compte provenant d’un ou de plusieurs de vos comptes détenus ou abonnés via une seule connexion.
Vous recevrez toutes les activités ci‑dessous pour chaque abonnement utilisateur sur votre enregistrement de webhook :
| Types d’activité | |
|---|
* Posts (par l’utilisateur)
* Suppressions de Post (par l’utilisateur)
* @mentions (de l’utilisateur)
* Réponses (à ou de l’utilisateur)
* Retweets (par l’utilisateur ou concernant l’utilisateur)
* Quote Tweets (par l’utilisateur ou concernant l’utilisateur)
* Retweets de Quote Tweets (par l’utilisateur ou concernant l’utilisateur)
* Likes (par l’utilisateur ou concernant l’utilisateur)
* Follows (par l’utilisateur ou concernant l’utilisateur)
* Unfollows (par l’utilisateur) | * Blocages (par l’utilisateur)
* Déblocages (par l’utilisateur)
* Mises en sourdine (par l’utilisateur)
* Annulations de mise en sourdine (par l’utilisateur)
* Messages privés envoyés (par l’utilisateur)
* Messages privés 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 livrons pas les 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.
Découvrez notre série de vidéos en quatre volets sur l’Account Activity API pour être rapidement opérationnel.
Récapitulatif des fonctionnalités
-
Des questions ? Vous rencontrez des erreurs ?
-
Explorez nos exemples de code :
Gérer les webhooks et les utilisateurs abonnés
Ajout d’un webhook
Affichage d’un webhook
Suppression d’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 le webhook enregistré, veillez à consigner son id, car vous en aurez besoin ultérieurement.Copiez la requête cURL suivante dans votre terminal après avoir remplacé les valeurs suivantes :
-
URL
<URL> p. ex. https://yourdomain.com/webhooks/twitter/
-
Consumer key
<CONSUMER_KEY> p. ex. xvz1evFS4wEEPTGEFPHBog
-
Access token
<ACCESS_TOKEN> p. 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"'
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 effectué les modifications suivantes :
-
Webhook ID
<:WEBHOOK_ID> p. ex. 1234567890
-
Nom de la clé consommateur (consumer key)
<CONSUMER_KEY> p. ex. xvz1evFS4wEEPTGEFPHBog
-
Access token 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"'
Présentation 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
-
Des questions ? Vous rencontrez des erreurs ?
-
Découvrez nos Exemples de code :
Enterprise
Premiers pas avec les webhooks
- Créez une X app avec un compte développeur approuvé depuis le developer portal. Si vous créez l’App pour le compte de votre entreprise, il est recommandé de la créer avec un compte X professionnel. 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 le Consumer Key (API Key) et le Consumer Token (API Secret) de votre App.
- Dans le même onglet, générez l’Access Token and Access Token Secret de votre App. Vous aurez besoin de ces Access Tokens pour enregistrer l’URL de votre webhook, où X enverra les événements de compte.
- Si vous ne connaissez pas X Sign-in et le fonctionnement des contextes utilisateur avec la X API, consultez Obtaining Access Tokens. Lorsque vous ajoutez des comptes pour lesquels recevoir des événements, vous vous y 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 » du developer portal. Lorsque vous demanderez l’accès à l’Account Activity API, vous aurez besoin de cet id d’App.
2. Obtenir l’accès à l’Account Activity API
3. Développer une app consommatrice de webhook
-
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 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 de type CRC (Challenge Response Check) de X et qui répond avec une réponse JSON correctement formatée.
-
Enregistrez l’URL de votre webhook. Vous effectuerez une requête POST vers l’endpoint /webhooks.json?url=. Lorsque vous ferez cette requête, X émettra une requête CRC vers votre application web. Lorsqu’un webhook est enregistré avec succès, la réponse inclut un webhook id. Cet id de webhook sera nécessaire ultérieurement pour certaines requêtes vers l’Account Activity API.
-
X enverra des é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 charges utiles JSON de webhook.
-
Une fois que votre application web est prête, l’étape suivante consiste à ajouter des comptes pour lesquels recevoir des activités. Lors de l’ajout (ou de la suppression) de comptes, vous effectuerez des requêtes POST en référencant 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 un favori à un Post publié 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 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, ainsi qu’avec l’access token utilisateur et le secret du propriétaire de l’App.
-
Tous les Messages privés entrants seront livrés via des webhooks. Tous les Messages privés envoyés via POST direct_messages/events/new (message_create) seront également livrés via des webhooks. Cela permet à votre application web d’être informée des Messages privés envoyés via un client différent.
-
Notez que chaque événement de webhook inclut un for_user_id (ID utilisateur) qui indique pour quel abonnement l’événement a été livré.
-
Si deux utilisateurs utilisent votre application web pour les Messages privés dans la 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 App, 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 webhook doit être tolérante à cela et effectuer une déduplication par ID d’événement.
-
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 fournir une réponse Quick Reply à une demande à laquelle il n’a pas répondu plus tôt dans le fil de messages.
-
Voir du code d’exemple :
- Enterprise Account Activity API dashboard, une application web Node qui affiche les événements de webhook en utilisant le niveau Enterprise de l’Account Activity API et inclut la fonctionnalité Replay.
- Le chatbot SnowBot, une application web Ruby construite sur les API Account Activity et Messages privés. Cette base de code 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 la propriété de l’application web qui reçoit les événements de webhook.
- L’en-tête de signature présent dans chaque requête POST vous permet de confirmer que X est bien la source des webhooks entrants.
Vérifications par défi-réponse
crc_token. Lorsque cette requête est reçue, votre application web doit générer un response_token chifré à partir du paramètre crc_token et du Consumer Secret de votre App (détails ci-dessous). Le response_token doit être encodé en JSON (voir l’exemple ci-dessous) et renvoyé dans un délai de trois secondes. En cas de succès, un id de webhook sera renvoyé.
Un CRC sera envoyé lorsque vous enregistrez votre URL de webhook, donc implémenter votre code de réponse CRC est une première étape fondamentale. Une fois votre webhook établi, X déclenchera un CRC environ toutes les 24 heures à partir de la dernière fois où nous avons reçu une réponse réussie. Votre App 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 pendant le développement de votre application webhook, après le déploiement d’un nouveau code et le redémarrage de votre service.
Le crc_token est susceptible de changer pour chaque requête CRC entrante et doit être utilisé comme message dans le calcul, avec votre Consumer Secret comme 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é.
- Lors de l’enregistrement d’une URL de webhook.
- Environ toutes les heures pour valider votre URL de webhook.
- Vous pouvez déclencher manuellement un CRC en envoyant une requête PUT. Pendant le développement de votre client de webhook, prévoyez de déclencher manuellement le CRC à mesure que vous implémentez votre réponse CRC.
Exigences relatives à la réponse :
- Un hash HMAC SHA-256 encodé en base64, créé à partir du
crc_token et du Consumer Secret de votre App
- Un
response_token valide et un format JSON.
- Une latence inférieure à 3 secondes.
- Un code de réponse HTTP 200.
Bibliothèques HMAC propres à chaque 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 hash HMAC SHA-256 à partir du jeton entrant et de votre secret consommateur
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 hash 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 présente un exemple de méthode de réponse CRC écrite en Node/JS.
- ICI présente 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 de X, de l’envoi d’une requête GET pour créer un webhook ou d’une requête GET pour effectuer un CRC manuel, une signature de hash est transmise dans les en-têtes sous la forme x-twitter-webhooks-signature. Cette signature peut être utilisée pour vérifier que la source des data est X. La signature de hash pour les requêtes POST commence par sha256=, indiquant l’utilisation de HMAC SHA-256 pour signer votre X App Consumer Secret et la charge utile. Le hash pour les requêtes GET est calculé à partir de la chaîne du paramètre query crc_token=token&nonce=nonce.
Étapes pour valider une requête
- Créez un hash à l’aide de votre consumer secret et du corps de la charge utile entrante.
- Comparez le hash obtenu 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
-
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 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 (en raison de POODLE)
- Désactiver TLS 1.0
- Désactiver TLS 1.1
- Désactiver la compression TLS
- Désactiver les tickets de session, sauf si vous faites tourner les 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 des suites cryptographiques est moderne, par exemple :
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
Endpoints de gestion de la configuration des webhooks :
Pourquoi ne puis-je pas simplement mettre à jour l’URL du webhook ?
Ajout et suppression d’abonnements utilisateur
Endpoints de gestion des abonnements
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, assurez-vous de communiquer l’id de l’App que vous comptez utiliser à des fins d’authentification à votre account manager ou à l’équipe de support technique.
- Consumer Keys (API Key et Secret)
- Access Tokens (Access Token et Secret)
Dans le cas des trois endpoints suivants, vous effectuez des opérations 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 développeur. Ceux-ci peuvent être générés directement depuis le developer portal, sous l’onglet « Keys and tokens » de votre App.
D’autre part, pour les 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 Access Tokens appartenant à l’utilisateur abonné concerné. Les Access Tokens requis peuvent être obtenus à l’aide du flux OAuth à 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 (*).
Veuillez noter : 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. Veuillez noter : X doit activer l’accès à l’Account Activity API pour votre App développeur avant que vous ne puissiez commencer à utiliser l’API. À cette fin, veillez à partager l’App ID que vous comptez utiliser à des fins d’authentification avec votre account manager ou votre équipe d’assistance technique.
- 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 à fournir sont ceux de votre App développeur. Ils peuvent être générés directement depuis le developer portal, 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 au nom d’un utilisateur X (par exemple, des Messages privés). Vous devez donc fournir les Access Tokens appartenant à l’utilisateur abonné concerné. Les Access Tokens requis peuvent être obtenus à l’aide du flux OAuth à 3 étapes (voir OAuth 1.0a : comment obtenir les Access Tokens d’un utilisateur). Ces endpoints sont marqués d’un astérisque dans le tableau ci-dessus (*).
Veuillez noter : 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 autorisations. Enterprise
L’un des avantages de l’offre Enterprise de l’Account Activity API est la prise en charge des réessais 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 et renvoie 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 améliore la fiabilité et permet la récupération des événements en cas de problèmes réseau, ainsi que lors des interruptions et déploiements côté client.
Qu’est-ce que les tentatives de renvoi (retries) ?
Chronologie des nouvelles tentatives
Chronologie des tentatives de renvoi
|
|---|
| Activité créée, POST vers l’URL du webhook depuis l’Account Activity API, puis délai d’expiration au bout de trois secondes. |
| Attendre trois secondes après la fin du délai précédent, puis effectuer un POST vers l’URL du webhook depuis l’Account Activity API, avec expiration au bout de trois secondes. |
| Attendre 27 secondes après la fin du délai précédent, puis effectuer un POST vers l’URL du webhook depuis l’Account Activity API, avec expiration au bout de trois secondes. |
| Attendre 242 secondes après la fin du délai précédent, puis effectuer un POST vers l’URL du webhook depuis l’Account Activity API, avec expiration au bout de trois secondes. |
| L’Account Activity API cessera ensuite de tenter des POST. Le client doit utiliser d’autres endpoints X pour récupérer les data. |
Structure de l’objet de données Account Activity
| Objet | Détails |
|---|
| for_user_id | Identifie l’abonnement utilisateur auquel l’événement est associé. |
| is_blocked_by | (conditionnel) Affiché uniquement lorsqu’un autre utilisateur mentionne votre utilisateur abonné. Inclus si true pour les événements de mention de Post uniquement. |
| source | L’utilisateur qui réalise l’activité. Par exemple, l’utilisateur qui suit, bloque ou met en sourdine est l’utilisateur source. |
| target | L’utilisateur sur lequel l’activité s’applique. 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 Post lorsque l’une des actions suivantes est effectuée par ou envers l’utilisateur abonné : Posts, Retweets, réponses, @mentions, QuoteTweets, Retweet de QuoteTweets. |
| favorite_events | Événement de favori (like) 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 de réactivation de la 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 direct avec l’utilisateur et la cible lorsqu’un message direct est envoyé ou reçu. |
| direct_message_indicate_typing_events | Événement d’indication de saisie de message direct avec l’utilisateur et la cible. |
| direct_message_mark_read_events | Événement de lecture de message direct avec l’utilisateur et la cible. |
| tweet_delete_events | Notification de Posts supprimés pour faciliter la conformité. |
Exemples de charge utile
Consultez ci-dessous les exemples de charge utile pour chaque événement Account Activity décrit dans le tableau ci-dessus.
{
"for_user_id": "2244994945",
"tweet_create_events": [
{
<Objet Tweet>
}
]
}
{
"for_user_id": "2244994945",
"user_has_blocked": "false",
"tweet_create_events": [
{
<Objet Tweet>
}
]
}
événements_favoris
{
"for_user_id": "2244994945",
"favorite_events": [{
"id": "a7ba59eab0bfcba386f7acedac279542",
"created_at": "Mon Mar 26 16:33:26 +0000 2018",
"timestamp_ms": 1522082006140,
"favorited_status": {
<Objet Tweet>
},
"user": {
<Objet utilisateur>
}
}]
}
follow_events
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "follow",
"created_timestamp": "1517588749178",
"target": {
<Objet utilisateur >
},
"source": {
< Objet utilisateur >
}
]
}
}
événements_désabonnement
{
"for_user_id": "2244994945",
"follow_events": [{
"type": "unfollow",
"created_timestamp": "1517588749178",
"target": {
<Objet utilisateur >
},
"source": {
< Objet utilisateur >
}
]
}
}
block_events
{
"for_user_id": "2244994945",
"block_events": [{
"type": "block",
"created_timestamp": "1518127020304",
"source": {
<Objet utilisateur>
},
"target": {
<Objet utilisateur>
}
}]
}
unblock_events
{
"for_user_id": "2244994945",
"block_events": [{
"type": "unblock",
"created_timestamp": "1518127020304",
"source": {
<Objet utilisateur>
},
"target": {
<Objet utilisateur>
}
}]
}
mute_events
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "mute",
"created_timestamp": "1518127020304",
"source": {
<Objet utilisateur>
},
"target": {
<Objet utilisateur>
}
}
]
}
unmute_events
{
"for_user_id": "2244994945",
"mute_events": [
{
"type": "unmute",
"created_timestamp": "1518127020304",
"source": {
<Objet utilisateur>
},
"target": {
<Objet utilisateur>
}
}
]
}
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": "Bonjour le monde !",
"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 opinions-are-my-own",
"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"
}
}
}
événements_marquer_message_direct_comme_lu
{
"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": "données le jour @X, design le soir",
"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 mes-opinions-personnelles",
"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 de relecture de l’activité de compte
Enterprise
L’API de relecture de l’activité de compte est un outil de récupération de données qui permet de rétablir des événements jusqu’à cinq jours en arrière. Elle doit être utilisée pour récupérer des données lorsque votre serveur webhook rate des événements — que ce soit en raison de déconnexions plus longues que la fenêtre de nouvelle tentative, ou dans des scénarios de reprise après sinistre où vous avez besoin de quelques jours pour remettre votre système à l’état nominal.
L’API de relecture de l’activité de compte a été conçue pour tout scénario dans lequel vous ne parvenez pas à ingérer des activités pendant une certaine période. Elle remet les activités au même webhook que celui utilisé pour la diffusion en temps réel d’origine. Ce produit est un outil de récupération et non un outil de reconstitution a posteriori, ce qui signifie que les événements ne seront rejoués que si une tentative de livraison antérieure a eu lieu. L’API de relecture de l’activité de compte ne peut pas livrer des événements pour une période antérieure à la date de création d’un abonnement.
Utilisation de l’API Account Activity Replay
Disponibilité et types de données
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 proposons de nouveaux endpoints et services offrant un accès similaire et, pour les Messages privés, des fonctionnalités supplémentaires :
Pour vous aider à migrer en douceur vers ces nouveaux endpoints et services, nous proposons deux guides de migration :
De plus, nous proposons une série de vidéos sur l’Account Activity API et la prise en main.
Enfin, nous proposons des exemples de code pour approfondir votre compréhension et vous aider à démarrer rapidement :
- Le 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 des Messages privés. 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 à Account Activity API
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’Account Activity API
- Nombre de webhooks nécessaires
- Abonnements/utilisateurs autorisés actuels/prévus gérés sur votre application
- Nombre actuel d’applications clientes X
- Niveau de support souhaité de la part de X (support via forum ou support géré Enterprise 1:1)
- Prix de chaque offre
Étape 2 : Vérifiez la configuration de votre X App dans le developer portal
La X App actuellement utilisée pour User Streams ou Site Streams sera répertoriée pour l’utilisateur propriétaire dans le developer portal. Cette X App peut également être utilisée pour l’Account Activity API afin de conserver les utilisateurs autorisés pour cette application. Une nouvelle App peut aussi être créée, et les utilisateurs peuvent être de nouveau autorisés pour cette nouvelle App si vous le souhaitez. Si vous créez une nouvelle App pour le compte d’une entreprise, il est recommandé de la créer avec un compte X @handle d’entreprise.
- Activez « Read, Write and Access direct messages » dans l’onglet permissions de la page de votre X App.
*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 de son autorisation. Si un utilisateur ne vous a pas encore accordé l’accès en lecture, écriture et aux Messages privés, vous devrez lui demander de réautoriser votre application.
- Si vous n’êtes pas familier avec X Sign-in et le fonctionnement des contextes utilisateur avec la X API, consultez Obtaining Access Tokens.
- Générez des access tokens pour le propriétaire de la X App au bas de l’onglet « Keys and Tokens ». Dans ce même onglet, relevez 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 des événements (par ex. 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 renvoyer une réponse JSON contenant un response_token qui est un hash HMAC SHA-256 encodé en base64, créé à partir du crc_token et du Consumer Secret de votre App.
-
Consultez la documentation Securing Webhooks en prêtant une attention particulière aux exigences du 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 webhook sécuriseront vos webhooks de deux manières :
- Exiger des vérifications Challenge Response pour valider que le propriétaire du webhook est bien 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 renvoyer une réponse JSON contenant un response_token qui est un hash HMAC SHA-256 encodé en base64, créé à partir du crc_token et du Consumer Secret de votre App.
- Attendez-vous à ce que le crc_token change 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 vers le webhook enregistré cessera.
Étape 5 : Créer des abonnements pour chaque utilisateur autorisé dans User Streams ou Site Streams
Conversion vers l’Account Activity API depuis 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 de control streams) :
- 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 (hors migration depuis Site Streams ou User Streams)
Tableau de bord Account Activity (application d’exemple Account Activity API)
- 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’App
- Une fois l’application lancée, vous pouvez utiliser l’interface pour configurer facilement votre webhook et créer un nouvel abonnement
Types de messages de stream obsolètes
| |
|---|
| Lignes vides | Les lignes vides ne seront plus envoyées via l’Account Activity API, car elles étaient utilisées comme messages de keep-alive dans User Streams et Site Streams. |
| Avis de limitation | Les avis de limitation ne seront plus envoyés à un webhook donné. À la place, les utilisateurs peuvent appeler l’API pour obtenir l’usage actuel des handles disponibles. Cela sera ajouté au developer portal à une date ultérieure. |
| Messages de déconnexion | Les avis de déconnexion ne seront plus nécessaires, car les webhooks ne dépendent pas d’une connexion active. |
| Avertissements de blocage | Les avertissements de blocage ne seront plus nécessaires, car les webhooks ne dépendent pas d’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. Un endpoint REST sera désormais disponible pour obtenir cette information. |
Types d’événements obsolètes
| | | | |
|---|
| Description | Nom de l’événement | Source | Cible | Objet cible |
| L’utilisateur supprime un Post | delete | Utilisateur actuel | Utilisateur actuel | Post |
| Un utilisateur suivi supprime un Post | delete | Utilisateur suivi | Utilisateur suivi | Post |
| L’utilisateur retire un Post de ses favoris | unfavorite | Utilisateur actuel | Auteur du Post | Post |
| Un Post de l’utilisateur est retiré des favoris | unfavorite | Utilisateur retirant des favoris | Utilisateur actuel | Post |
| L’utilisateur ne suit plus quelqu’un | unfollow | Utilisateur actuel | Utilisateur suivi | Null |
| L’utilisateur crée une List | list_created | Utilisateur actuel | Utilisateur actuel | List |
| L’utilisateur supprime une List | list_destroyed | Utilisateur actuel | Utilisateur actuel | List |
| L’utilisateur modifie une List | list_updated | Utilisateur actuel | Utilisateur actuel | List |
| L’utilisateur ajoute quelqu’un à une List | list_member_added | Utilisateur actuel | Utilisateur ajouté | List |
| L’utilisateur est ajouté à une List | list_member_added | Utilisateur ajoutant | Utilisateur actuel | List |
| L’utilisateur retire quelqu’un d’une List | list_member_removed | Utilisateur actuel | Utilisateur retiré | List |
| L’utilisateur est retiré d’une List | list_member_removed | Utilisateur retirant | Utilisateur actuel | List |
| L’utilisateur s’abonne à une List | list_user_subscribed | Utilisateur actuel | Propriétaire de la List | List |
| La List de l’utilisateur reçoit un abonnement | list_user_subscribed | Utilisateur s’abonnant | Utilisateur actuel | List |
| L’utilisateur se désabonne d’une List | list_user_unsubscribed | Utilisateur actuel | Propriétaire de la List | List |
| La List de l’utilisateur perd un abonnement | list_user_unsubscribed | Utilisateur se désabonnant | Utilisateur actuel | List |
| 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
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 à l’aide d’une liste d’options prédéfinies.
- Accès aux Messages privés des 30 derniers jours.
Pour la liste complète des nouvelles fonctionnalités des Messages privés et des nouveaux endpoints d’API, consultez la documentation technique.
Différences et considérations de migration
Nouvel objet Messages privés
{
"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": "Oiseau Bleu",
"entities": {
"hashtags": [],
"symbols": [],
"urls": [],
"user_mentions": [],
},
"quick_reply_response": {
"type": "options",
"metadata": "external_id_2"
},
"attachment": {
"type": "media",
"media": {
...
}
}
}
}
- Structure d’objet Direct Message entièrement nouvelle.
- Objet utilisateur condensé.
- Nouvelles informations disponibles (réponses de « quick reply », pièces jointes, etc.).
POST direct_messages/events/new remplace directement l’envoi de Messages privés. La principale différence avec cet endpoint est que toutes les informations sont désormais envoyées au format JSON dans le corps de la requête POST, plutôt que sous forme de paramètres POST individuels.
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": "Bonjour tout le monde !"}}}}'
- 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 sur application/json
- Le corps JSON n’est pas inclus dans la génération de la signature OAuth.
Récupération des Messages privés
sender_id.
La pagination est désormais basée sur une valeur de curseur plutôt que sur l’id d’un Message privé. Une propriété de curseur est renvoyée avec chaque réponse. GET direct_messages/events/list renverra jusqu’à 30 jours de messages, quel que soit le nombre de messages envoyés au cours des 30 derniers jours. Lorsqu’aucun curseur n’est renvoyé, il n’y a plus de messages à récupérer. La méthode d’accès aux Messages privés individuels avec GET direct_messages/events/show reste la même, bien que l’objet Message privé renvoyé ait une structure différente, comme décrit précédemment.
Enfin, l’accès en temps réel aux Messages privés s’effectue désormais via webhook avec l’Account Activity API. Pour des conseils de migration depuis User Streams ou Site Streams, consultez le guide de migration vers l’Account Activity API pour plus d’informations.
- Les messages envoyés et reçus sont désormais renvoyés via le même endpoint.
- Jusqu’à 30 jours de messages sont renvoyés.
- Pagination basée sur un curseur.
- Accès en temps réel aux Messages privés via webhook.
Suppression des Messages privés
- La suppression d’un Message privé nécessite l’id.
- Le nouvel endpoint requiert une requête DELETE.
- La manière dont les Messages privés supprimés sont reflétés dans les clients officiels X reste inchangée.
Des questions sur la migration vers les nouveaux endpoints de Messages privés ?
Publiez 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 que, contrairement aux API de streaming, nous n’exigeons pas que vous mainteniez une connexion ouverte pour que nous vous envoyions des informations. Les webhooks diffèrent également 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, puisqu’ils livrent les données au moment où elles surviennent.
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 livrées dans l’API comprennent les Posts, les @mentions, les réponses, les Retweets, les Quote Tweets, les Retweets de Quote Tweets, les likes, les Messages privés envoyés, les Messages privés reçus, les abonnements, les blocages et les mises en sourdine.
- Passage à l’échelle : 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 versions bac à sable Premium, Premium payante et Enterprise, afin que vous puissiez évoluer selon vos besoins en fonctionnalités de conformité ou en fonctionnalités supplémentaires.
Pour commencer, téléchargez des extraits d’exemples de code depuis GitHub.
Comment identifier quelle offre produit me convient le mieux ?
Veuillez lire notre page Présentation de l’Account Activity API 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 en a aucune. 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 chacun via les méthodes de l’API. En outre, plusieurs Apps clientes peuvent être ajoutées à une allowlist pour maintenir l’autorisation de vos utilisateurs actuellement autorisés.
Avez-vous des guides étape par étape pour configurer l’Account Activity API ?
En effet !
-
Si vous débutez, nous vous recommandons de consulter notre guide Bien démarrer avec les webhooks
-
Suivez nos scripts pris en charge par X Dev :
- Tableau de bord Account Activity API, une application web Node qui affiche les événements webhook.
- Le chatbot SnowBot, une application web Ruby construite sur les API Account Activity et Direct Message. 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 en panne 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 les 7 jours.
Nous vous suggérons d’utiliser vos différents webhooks, ou environnements, comme outil de redondance, par exemple l’Account Activity Replay API, afin de vous assurer que vous ne manquez aucune activité si l’un de vos systèmes tombe en panne.
Quelle 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 débutez avec l’authentification X, nous vous recommandons de lire cette section.
Qu’est-ce qu’un contrôle par challenge-response (CRC) ?
Le contrôle de réponse au défi (challenge response) de l’Account Activity API est une fonctionnalité de sécurité destinée à 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 reçues proviennent bien de X. X enverra automatiquement un CRC à votre URL de webhook toutes les 24 heures, à compter de la dernière validation de l’URL du webhook. 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 éléments 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. Dans ce cas, notre système ne réessaiera pas de vous envoyer l’activité.
- Votre serveur renvoie un code de réponse non 2XX, non 4XX, non 5XX.
- Vous indiquez l’utilisation de gzip sans réellement l’envoyer.
- Vous n’indiquez pas l’utilisation de gzip, mais vous l’envoyez malgré tout 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 un Post, deux activités POST seront envoyées au webhook enregistré. Chaque activité comportera un indicateur “for_user_id” indiquant à quel abonnement l’activité appartient.
Lorsque je crée un abonnement à mon webhook, puis-je remplacer la partie /all/ de l’endpoint suivant par d’autres objets de données d’activité de compte 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, seul le produit /all/ est disponible.
Existe-t-il un moyen d’utiliser l’Account Activity API sans demander les autorisations Messages privés aux utilisateurs ?
À ce stade, les autorisations Messages privés sont requises, car il n’existe aucun moyen d’« exclure » les activités de Messages privés pour cette API.
Existe-t-il une version gratuite de l’Account Activity API ?
Oui, nous proposons la version sandbox comme palier gratuit. Notre option sandbox est limitée à un seul webhook avec un maximum de 15 abonnements. 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 Posts qui mentionnent des utilisateurs abonnés ?
Malheureusement, cela ne fait pas partie des activités livrées avec cette API. Pour cela, nous suggérons d’utiliser 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 un Post
- Effectue un Retweet
- Répond à un Post
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 l’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 Post.
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 allowlist pour l’accès via les Enterprise APIs, veuillez contacter votre account manager avec votre app ID. Vous pouvez trouver votre app ID en accédant à la page “Apps” dans le developer portal.
Si j’ai accès à trois webhooks, puis-je utiliser trois webhooks pour chacune des apps que j’ai enregistrées pour une utilisation Enterprise ?
La limite de webhooks est définie au niveau du compte, et non au niveau de l’app. Si vous avez accès à trois webhooks et à deux apps enregistrées pour une utilisation Enterprise, vous pouvez utiliser deux webhooks sur une app et le troisième sur l’autre app, mais pas trois sur chaque app.
Puis-je spécifier quels types d’événements seront relivré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 livrés pendant la fenêtre de date et d’heure indiquée seront rejoués.
Y aura-t-il des tentatives de nouvel envoi si mon application ne parvient pas à ingérer un événement de l’Account Activity Replay API ?
Non, il n’y aura pas de nouvelle tentative. Si une application ne parvient pas à ingérer un événement envoyé par l’Account Activity Replay API, un autre Replay job peut être soumis pour la même période afin de tenter la relivraison des Replay events manqués.
Que dois-je faire lorsque je reçois un événement d’achèvement avec succès partiel ?
Nous vous suggérons de relever les horodatages des événements reçus et de demander un autre Replay job pour les événements manqués.
Combien de jobs Account Activity Replay API puis-je exécuter simultanément ?
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 ?
Comme l’Account Activity Replay API livrera toujours des événements passés, ils peuvent être différenciés des événements de production en temps réel sur la base de l’horodatage de l’événement.
Dans quel délai puis-je commencer à utiliser l’Account Activity Replay API pour relivrer une activité que mon application a abandonnée ou manquée ?
Une activité devient disponible pour relivraison environ 10 minutes après sa création.
Guide de résolution des erreurs
-
Enterprise - Assurez-vous que les clés consommateur et les access tokens que vous utilisez appartiennent à une X app enregistrée pour l’utilisation des produits Enterprise. Si vous n’avez pas vos clés consommateur et access tokens, ou si vous devez ajouter votre X app à la allowlist, veuillez contacter votre gestionnaire 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 disposent du niveau d’autorisation approprié.
- Dans l’onglet “Keys and tokens” du app dashboard, assurez-vous que vos access tokens disposent du niveau d’autorisation “Read, write, and direct messages” permission level.
- Si le niveau d’autorisation des jetons est inférieur à celui-ci, rendez-vous dans l’onglet “Permissions”, définissez l’autorisation d’accès sur “Read, write, and direct messages”, puis régénérez vos access tokens et leur secret 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 à l’API. Vous devez également utiliser le :env_name approprié dans la requête, que vous pouvez configurer sur la page dev environments.
-
Enterprise - Assurez-vous que votre responsable de compte vous a accordé l’accès à l’Account Activity API.
-
Assurez-vous d’avoir correctement configuré votre URI. Cette erreur peut se produire si vous avez renseigné une URI incorrecte dans votre requête.
Code 214 - L’URL du webhook ne répond pas aux exigences.
Code 214 - Latence élevée sur la requête GET de CRC. Votre webhook doit répondre en moins de 3 secondes.
- Cela signifie que votre serveur est lent. Assurez-vous de répondre au CRC en moins de 3 secondes.
Code 214 - Code de réponse non 200 lors de la requête CRC GET (p. ex. 404, 500, etc.).
- Votre serveur est indisponible. 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 Apps enregistrées pour identifier où vos webhooks sont déployés.
- L’App que vous utilisez avec l’API n’a pas le niveau d’autorisation approprié défini pour son Access Token et son Access Token Secret. Accédez à l’onglet « Keys and tokens » dans le tableau de bord X apps et vérifiez les niveaux d’autorisation attribués à votre Access Token et à votre Access Token Secret. S’il est réglé sur autre chose que « Read, write and Direct Messages », vous devrez ajuster les paramètres dans l’onglet « Permission » et régénérer votre Access Token et votre Access Token Secret pour appliquer les nouveaux paramètres.
- Autrement, vous essayez d’enregistrer un webhook avec une authentification App-only, ce qui n’est pas pris en charge. Veuillez plutôt vous authentifier avec un contexte utilisateur, comme indiqué dans les sections de référence de l’API pour l’enregistrement d’un webhook pour l’Enterprise Account Activity API.
Index de référence de l’Account Activity API
Account Activity API Enterprise
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 l’enregistrement. En cas d’échec de la validation, renvoie au demandeur un message d’erreur complet.
Le nombre de webhooks autorisés est déterminé par l’offre de facturation.
https://api.x.com/1.1/account_activity/webhooks.json
| |
|---|
| Format de réponse | JSON |
| Authentification requise | Oui (contexte utilisateur — tous les consumers et access tokens) |
| Limitation de taux | 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 d’édition 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 pour l’endpoint de rappel. |
$ 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“‘
| Code HTTP | Message |
|---|
| 200 | L’URL de webhook est enregistrée pour l’App indiquée |
| 403 | Une erreur s’est produite dans votre requête. Voir la section des messages d’erreur ci-dessous. |
Exemple de réponse – Succès
_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 satisfait pas aux exigences. |
| 214 | Trop de ressources déjà créées. |
| 214 | L’URL du webhook ne satisfait pas aux exigences. Jeton CRC invalide ou format de réponse JSON invalide. |
| 214 | Latence élevée lors de la requête GET CRC. Votre webhook doit répondre en moins de 3 secondes. |
| 214 | Code de réponse non 200 lors de la requête GET CRC (p. ex. 404, 500, etc.). |
HTTP 403
{
"errors": [
{
"code": 214,
"message": "Trop de ressources ont déjà été créées."
}
]
}
GET account_activity/webhooks
Renvoie toutes les URL et leurs statuses pour l’App donnée.
Nous marquons une URL comme invalide si elle échoue à la vérification quotidienne. Pour réactiver l’URL, appelez l’endpoint de mise à jour.
https://api.x.com/1.1/account_activity/webhooks.json
| |
|---|
| Format de réponse | JSON |
| Authentification requise | Oui (application uniquement — Jeton Bearer) |
| Limite de taux | Oui |
| Requêtes / fenêtre de 15 minutes (authentification de l’application) | 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"
}
]
| 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 indiqué. Si la vérification réussit, renvoie 204 et réactive le webhook en définissant son statut sur valid.
https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json
| |
|---|
| Format de réponse | JSON |
| Authentification requise | Oui (contexte utilisateur - tous les consommateurs et Access Tokens) |
| Limité par une limite de taux | Oui |
| Requêtes par fenêtre de 15 minutes (authentification utilisateur) | 15 |
| |
|---|
| webhook_id (required) | id du 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"'
| Code | Message |
|---|
| 34 | Le webhook n’existe pas ou est associé à une autre X App. |
| 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 invalide. |
| 214 | Latence élevée lors de la requête CRC en GET. Votre webhook doit répondre en moins de 3 secondes. |
| 214 | Code de réponse non 200 lors de la requête CRC en GET (p. ex. 404, 500, etc.). |
POST account_activity/webhooks/:webhook_id/subscriptions/all
Abonne l’App fournie à tous les événements dans le contexte utilisateur spécifié, pour tous les types de messages. Après activation, tous les événements concernant l’utilisateur requérant 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 devez ajouter davantage d’abonnements, veuillez contacter votre responsable de compte.
URL de la ressource
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| Format de réponse | JSON |
| Authentification requise | Oui (OAuth à 3 étapes – clé consommateur autorisée et access token de l’utilisateur abonné) |
| Soumis à une limite de taux | Oui |
| Requêtes / fenêtre de 15 minutes (authentification utilisateur) | 500 |
Paramètres
| |
|---|
| webhook_id (obligatoire) | ID du webhook. Défini dans le chemin de 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
| Code | Message |
|---|
| 34 | Le webhook n’existe pas ou est associé à une autre App X. |
| 348 | L’App 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 l’endpoint /count nécessite l’authentification OAuth en mode App uniquement ; vous devez donc effectuer vos requêtes en utilisant un Jeton Bearer plutôt qu’un contexte utilisateur.
URL de la ressource
https://api.x.com/1.1/account_activity/subscriptions/count.json
| |
|---|
| Format de réponse | Code de réponse HTTP |
| Authentification requise | Oui (App uniquement — Jeton Bearer) |
| Limité par une limite de taux | Oui |
| Requêtes / fenêtre de 15 minutes (authentification App) | 15 |
| |
|---|
| Code | Message |
| 200 | Réussite. Un nombre d’abonnements pour le webhook demandé sera renvoyé. |
| 401 | Votre App n’a pas l’autorisation d’afficher les abonnements pour le webhook spécifié. |
$ 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
{
"account_name":"mon-compte",
"subscriptions_count_all":"1",
"subscriptions_count_direct_messages":"0",
"provisioned_count":"50"
}
| Code | Message |
|---|
| 32 | Impossible de vous authentifier. |
HTTP 401
{
"errors": [
{
"code": 32,
"message": "Impossible de vous authentifier."
}
]
}
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 context utilisateur fourni dispose d’un abonnement actif avec l’App fournie, renvoie 204 OK. Si le code de réponse n’est pas 204, l’utilisateur n’a pas d’abonnement actif. Voir les codes de réponse HTTP et les messages d’erreur ci‑dessous pour plus de détails.
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é consommateur autorisée et access token de l’utilisateur abonné) |
| Limite de taux | Oui |
| Requêtes / fenêtre de 15 minutes (authentification utilisateur) | 500 |
| |
|---|
| webhook_id (obligatoire) | id du webhook. Indiqué 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 - Réussite
GET account_activity/webhooks/:webhook_id/subscriptions/all/list
Retourne la liste des abonnements en cours de type All Activity pour le webhook spécifié. Notez que l’endpoint /list requiert l’authentification OAuth en mode application uniquement ; les requêtes doivent donc être effectuées à l’aide d’un Jeton Bearer plutôt qu’en contexte utilisateur.
URL de la ressource
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json
| |
|---|
| Format de la réponse | Code de réponse HTTP |
| Authentification requise | Oui (App uniquement — Jeton Bearer) |
| Limite de taux | Oui |
| Requêtes / fenêtre de 15 minutes (authentification App) | 50 |
| |
|---|
| webhook_id (obligatoire) | id du webhook. Défini dans le chemin de la ressource. |
| Code | Message |
|---|
| 200 | Opération réussie. Une liste d’abonnements pour le webhook demandé sera renvoyée. |
| 401 | Votre App n’a pas l’autorisation d’afficher 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
{
"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. |
HTTP 401
{
"errors": [
{
"code": 32,
"message": "Impossible de vous authentifier."
}
]
}
DELETE account_activity/webhooks/:webhook_id
Supprime le webhook de la configuration de l’App indiquée. L’id du webhook peut être obtenu en effectuant un appel GET à /1.1/account_activity/webhooks.
URL de ressource
https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json
| |
|---|
| Format de réponse | JSON |
| Authentification requise | Oui (contexte utilisateur — tous les consumers et access tokens) |
| Limite de taux | Oui |
| Requêtes par fenêtre de 15 minutes (authentification utilisateur) | 15 |
| |
|---|
| webhook_id (obligatoire) | id du webhook. Indiqué dans le chemin de ressource. |
$ 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)
Désactive l’abonnement ou les abonnements pour le contexte utilisateur et l’App fournis. Après la désactivation, tous les événements concernant l’utilisateur ayant effectué la requête ne seront plus envoyés à l’URL du webhook.
https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json
| |
|---|
| Format de réponse | JSON |
| Authentification requise | Oui (OAuth à 3 intervenants — clé consommateur autorisée et access token de l’utilisateur abonné) |
| Soumis à une limite de taux | Oui |
| Requêtes / fenêtre de 15 minutes (authentification utilisateur) | 500 |
| |
|---|
| webhook_id (obligatoire) | id du webhook. Défini dans le chemin de ressource. |
$ 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
Désactive l’abonnement pour le webhook et l’id utilisateur spécifiés. Après la désactivation, aucun événement concernant l’utilisateur demandeur ne sera plus envoyé à l’URL du webhook. Notez que cet endpoint requiert l’authentification OAuth en mode application uniquement ; les requêtes doivent donc être effectuées à l’aide 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/:user_id/all.json
| |
|---|
| Format de réponse | JSON |
| Authentification requise | Oui (application uniquement — Jeton Bearer) |
| Limite de taux | Oui |
| Requêtes / fenêtre de 15 min | 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'
| Code | Message |
|---|
| 404 | Désolé, cette page n’existe pas. - Cela survient souvent lorsque l’utilisateur spécifié par son id n’est en fait pas abonné. |
POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json ¶
Envoie une demande pour récupérer, sur une période allant jusqu’aux cinq derniers jours, les activités de toutes les abonnements présentes pendant les fenêtres de dates et heures spécifiées dans la requête. Si votre webhook a des abonnements utilisateur actifs, vous recevrez ces événements en parallèle. Remarque : un CRC est effectué avant la livraison des événements de relecture.
| |
|---|
| 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 taux | 5 requêtes par 15 minutes. Il n’y a actuellement aucune limite au nombre de tâches de relecture pouvant être demandées. |
| from_date | L’horodatage UTC le plus ancien (de début) à partir duquel les événements seront fournis, au format « yyyymmddhhmm ». L’horodatage est à la granularité de la minute et inclusif (p. ex. 12:00 inclut la minute 00). Les heures valides doivent se situer dans les 5 derniers jours, en UTC, et ne pas être plus récentes que 31 minutes avant l’instant présent. Il est recommandé que from_date et to_date couvrent un intervalle d’environ 2 heures. |
| to_date | L’horodatage UTC le plus récent (de fin) jusqu’auquel les événements seront fournis, au format « yyyymmddhhmm ». L’horodatage est à la granularité de la minute et exclusif (p. ex. 12:30 n’inclut pas la 30e minute de l’heure). Les heures valides doivent se situer dans les 5 derniers jours, en UTC, et ne pas être plus récentes que 10 minutes avant l’instant présent. |
Les réponses suivantes peuvent être renvoyées par l’API. La plupart des codes d’erreur sont renvoyés avec une chaîne incluant des détails supplémentaires dans le corps de la réponse. Pour les réponses autres que 200, vous devez corriger l’erreur et réessayer.
| Statut | Texte | Code d’erreur | Description | Message |
|---|
| 202 | Accepté | N/A | La requête a réussi et les activités seront envoyées. | N/A |
| 400 | Mauvaise requête | 214 | Le webhook a été marqué comme invalide. | Le webhook est marqué comme invalide et nécessite une vérification CRC. |
| 400 | Mauvaise requête | 357 | Le paramètre query est manquant. | : queryParam est requis. |
| 400 | Mauvaise requête | 358 | Le paramètre de route ou le paramètre query est mal formé. | Impossible d’analyser le paramètre. |
| 400 | Mauvaise requête | 360 | Le paramètre de route est négatif. | webhook_id: [] n’est pas supérieur ou égal à 0. |
| 400 | Mauvaise requête | 368 | from_date ou to_date n’est pas dans le passé. | : [<field_value>] n’est pas dans le passé. |
| 400 | Mauvaise requête | 356 | from_date doit être antérieur à to_date. | from_date doit être antérieur à to_date. |
| 400 | Mauvaise requête | 356 | from_date doit être dans les 5 derniers jours. | from_date doit être dans les 5 derniers jours. |
| 401 | Non autorisé | 32 | Échec de l’authentification HTTP en raison d’une authentification à 3 volets fournie. | Méthode d’authentification invalide. Veuillez utiliser l’authentification application-only. |
| 401 | Non autorisé | 61 | Le client n’est pas autorisé à appeler cette méthode. | Le client n’est pas autorisé à appeler cette méthode. |
| 403 | Interdit | 200 | Le client n’a pas de compte Enterprise avec Replay activé. | Un compte Enterprise de l’Account Activity API avec Replay est requis. Veuillez confirmer que vous disposez d’un compte Enterprise et que Replay est activé. |
| 404 | Introuvable | 34 | webhook_id inexistant ; discordance entre webhook_id et application_id. | Le webhook n’existe pas ou est associé à une autre application X. |
| 409 | Conflit | 355 | Une requête est en cours et doit se terminer avant d’en lancer une autre. | Un job de replay est déjà en cours pour ce webhook. |
| 429 | Trop de requêtes | 88 | Limite de taux atteinte (nombre de requêtes maximal sur une période donné). | Trop de requêtes. Veuillez réduire votre taux de requêtes à l’API. |
| 500 | Erreur interne du serveur | 0 | Erreur interne du serveur. | Erreur interne du serveur. |
| 503 | Service indisponible | 67 | Un ou plusieurs services dépendants chez X sont indisponibles. | Erreur du 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": "Tâche terminée avec succès"
"job_id": "1095098195724558337"
}
}
Message « Job failed to complete »
{
"replay\_job\_status": {
"webhook_id": "123451374207332352",
"job_state": "Incomplete",
"job\_state\_description": "La tâche a échoué dans la livraison de tous les événements, veuillez relancer votre tâche de relecture",
"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'
{
"job_id": "1234567890",
"created_at": "2016-06-02T23:54:02Z"
}
