Notifications X (anciennement Twitter)

Aperçu

• Source: https://x.com/
• Prise en charge des images: Non
• Prise en charge des pièces jointes: Oui
• Limites de caractères des messages:
  • Message direct: 10000
  • Tweet: 280
• Créer votre URL Apprise

Note

Apprise utilise l’API X v2 avec le contexte utilisateur OAuth 1.0a. La console de développement X affiche également des identifiants OAuth 2.0 et un jeton Bearer réservé à l’application, mais ces identifiants ne sont pas interchangeables et ne sont pas utilisés par cette intégration.

• Les publications (mode=tweet) nécessitent une application autorisée en lecture et écriture.
• Les messages directs (mode=dm, mode par défaut) nécessitent l’autorisation lecture, écriture et messages directs.

L’accès à l’API X est actuellement facturé à l’usage. Ajoutez des crédits et consultez les tarifs actuels des endpoints dans la documentation tarifaire de l’API X avant d’envoyer des notifications.

Configuration du compte

1. Connectez-vous à la console de développement X, puis créez ou sélectionnez une application.
2. Vérifiez que le compte développeur dispose de crédits pour l’utilisation de l’API.
3. Configurez les autorisations OAuth 1.0a de l’application :
   • choisissez Read and write pour publier des messages ;
   • choisissez Read, write, and Direct Messages pour envoyer des messages directs.
4. Générez et conservez les deux paires d’identifiants OAuth 1.0a :
   • API Key and Secret ;
   • Access Token and Secret.

Attention

X n’affiche les secrets qu’au moment de leur génération. Conservez les quatre valeurs en lieu sûr. Si vous n’avez pas enregistré un secret, régénérez la paire d’identifiants correspondante.

Après avoir modifié les autorisations OAuth 1.0a de l’application, régénérez l’Access Token and Secret afin que les nouveaux jetons reçoivent ces autorisations. Les jetons créés auparavant conservent leurs anciennes autorisations.

Associez les quatre valeurs aux éléments de l’URL Apprise comme suit :

Console de développement X	Élément de l’URL Apprise
API Key	ConsumerKey
API Key Secret	ConsumerSecret
Access Token	AccessToken
Access Token Secret	AccessSecret

Attention

Ne remplacez pas ces valeurs par un Client ID, un Client Secret, un Access Token ou un Refresh Token OAuth 2.0, et n’utilisez pas le jeton Bearer réservé à l’application. Apprise attend actuellement les quatre valeurs OAuth 1.0a ci-dessus.

Syntaxe

La syntaxe valide est la suivante (x://, twitter:// et tweet:// sont tous des alias acceptes) :

• x://{ConsumerKey}/{ConsumerSecret}/{AccessToken}/{AccessSecret}
• x://{ScreenName}@{ConsumerKey}/{ConsumerSecret}/{AccessToken}/{AccessSecret}

Si vous connaissez les cibles a identifier, vous pouvez les viser par leur nom d’utilisateur X, leur ScreenName :

• x://{ConsumerKey}/{ConsumerSecret}/{AccessToken}/{AccessSecret}/{ScreenName}
• x://{ConsumerKey}/{ConsumerSecret}/{AccessToken}/{AccessSecret}/{ScreenName1}/{ScreenName2}/{ScreenNameN}

Note

Les schémas x:// et twitter:// utilisent par défaut le mode Message Direct. Si aucun ScreenName n’est précisé, le message direct est envoyé au compte représenté par l’Access Token.

Utilisez ?mode=tweet ou l’alias tweet:// pour publier un message public.

Un tweet public peut etre reference ainsi (necessite un acces en ecriture a l’API X v2) :

• x://{ConsumerKey}/{ConsumerSecret}/{AccessToken}/{AccessSecret}?mode=tweet

Detail des Parametres

Variable	Obligatoire	Description
ScreenName	Non	Nom d’utilisateur X qui recevra le message direct, sans le caractère @. S’il est omis en mode DM, Apprise écrit au compte authentifié.
ConsumerKey	Oui	Clé API OAuth 1.0a de l’application X.
ConsumerSecret	Oui	Secret de la clé API OAuth 1.0a de l’application X.
AccessToken	Oui	Jeton d’accès OAuth 1.0a représentant le compte qui publiera le message ou enverra le message direct.
AccessSecret	Oui	Secret du jeton d’accès OAuth 1.0a associé à AccessToken.
Mode	Non	Utilisez tweet pour publier un message public ou dm pour envoyer un message direct. La valeur par défaut est dm.
batch	Non	Les images sont regroupées par défaut. Définissez cette valeur sur False pour publier un message par pièce jointe.

Paramètres Globaux

Variable	Description
overflow	Ce paramètre peut être défini sur split, truncate ou upstream. Il détermine la manière dont Apprise remet le message que vous lui transmettez. Par défaut, il vaut upstream. 👉 upstream : ne fait aucune modification et transmet le message exactement tel qu’il a été reçu au service. 👉 truncate : veille à ce que le message tienne dans la limite amont documentée par le service. Si plus d’informations sont fournies que la limite définie, l’excédent est tronqué. 👉 split : similaire à truncate, sauf que si le message dépasse la limite amont documentée par le service, il est découpé en plusieurs morceaux plus petits puis envoyés séquentiellement.
format	Ce paramètre peut être défini sur text, html ou markdown. Certains services prennent en charge plusieurs formats de publication du contenu. La valeur par défaut varie selon le service choisi et peut correspondre à l’un de ces trois formats. Vous pouvez facultativement forcer cette option pour vous écarter du comportement par défaut. Si le service ne prend pas en charge plusieurs formats de transmission, ce champ est ignoré.
verify	Les requêtes externes vers des emplacements sécurisés, par exemple via https, utilisent des certificats. Par défaut, Apprise vérifie la validité de ces certificats ; si ce n’est pas le cas, aucune notification n’est envoyée à la source. Dans certains cas, un utilisateur ne dispose pas d’une autorité de certification pour valider la clé ou fait simplement confiance à la source ; dans ce cas, vous pouvez définir ce drapeau sur no. Par défaut, il vaut yes.
redirect	Par défaut, Apprise suit les redirections HTTP (réponses 3xx) émises par le serveur distant, conformément au comportement de la bibliothèque requests sous-jacente. Si vous souhaitez empêcher la transmission des en-têtes personnalisés et des identifiants vers des destinations différentes de l’URL d’origine, définissez cette option sur no. Par défaut, elle vaut yes.
cto	Signifie Socket Connect Timeout. Il s’agit du nombre de secondes pendant lesquelles Requests attend que votre client établisse une connexion avec une machine distante, ce qui correspond à l’appel connect() sur la socket. La valeur par défaut est de 4.0 secondes.
rto	Signifie Socket Read Timeout. Il s’agit du nombre de secondes pendant lesquelles le client attend que le serveur envoie une réponse. La valeur par défaut est de 4.0 secondes.
emojis	Active la prise en charge des emojis, par exemple :+1: qui sera traduit en 👍. Par défaut, cette option vaut no. Remarque : selon la configuration côté serveur, l’administrateur peut désactiver globalement la prise en charge des emojis ; mais par défaut, ce n’est pas le cas.
tz	Identifie le fuseau horaire de la base IANA que vous souhaitez utiliser. Par défaut, celui-ci est détecté à partir de la configuration du serveur qui exécute Apprise. Vous pouvez le définir sur des valeurs comme America/Toronto, ou sur tout autre fuseau correctement formaté correspondant à votre région.
retry	Nombre de tentatives de remise supplémentaires après le premier échec, avant d’abandonner. Accepte un entier compris entre 0 et 10. La valeur par défaut est 0 (aucune nouvelle tentative — une seule tentative est effectuée). Lorsqu’il est combiné avec wait, Apprise marque une pause du nombre de secondes spécifié entre chaque tentative.
wait	Nombre de secondes à attendre entre les nouvelles tentatives. Accepte une valeur décimale comprise entre 0.0 et 20.0 ; les entiers sont automatiquement convertis en virgule flottante. La valeur par défaut est 0.5. Ce paramètre n’est utile que si retry est supérieur à zéro — un service avec retry=0 effectue exactement une tentative, quelle que soit la valeur de wait.
optional	Lorsqu’il est défini sur yes, un échec de remise pour ce service est silencieusement absorbé. L’appel global notify() retourne quand même True même si ce point de terminaison était injoignable, à condition que tous les services requis (non optionnels) du même lot aient réussi. Ce drapeau ne saute pas la remise ni ne contourne la logique de nouvelles tentatives — toutes les tentatives configurées sont effectuées avant que l’échec soit absorbé. Par défaut, il vaut no, ce qui signifie que chaque échec est propagé à l’appelant.

Exemples

Envoyer un tweet public (necessite un acces en ecriture a l’API X v2) :

# Supposons que notre {ConsumerKey} soit T1JJ3T3L2
# Supposons que notre {ConsumerSecret} soit A1BRTD4JD
# Supposons que notre {AccessToken} soit TIiajkdnlazkcOXrIdevi7F
# Supposons que notre {AccessSecret} soit FDVJaj4jcl8chG3
apprise -vv -t "Titre du Message de Test" -b "Corps du Message de Test" \
   x://T1JJ3T3L2/A1BRTD4JD/TIiajkdnlazkcOXrIdevi7F/FDVJaj4jcl8chG3?mode=tweet

Ou en utilisant l’alias de schema tweet:// (implique mode=tweet) :

apprise -vv -t "Titre du Message de Test" -b "Corps du Message de Test" \
   tweet://T1JJ3T3L2/A1BRTD4JD/TIiajkdnlazkcOXrIdevi7F/FDVJaj4jcl8chG3

Envoyer un message direct X a @testaccount (necessite les permissions d’ecriture DM de l’API X) :

# Supposons que notre {ConsumerKey} soit T1JJ3T3L2
# Supposons que notre {ConsumerSecret} soit A1BRTD4JD
# Supposons que notre {AccessToken} soit TIiajkdnlazkcOXrIdevi7F
# Supposons que notre {AccessSecret} soit FDVJaj4jcl8chG3
# notre utilisateur est @testaccount
apprise -vv -t "Titre du Message de Test" -b "Corps du Message de Test" \
   x://testaccount@T1JJ3T3L2/A1BRTD4JD/TIiajkdnlazkcOXrIdevi7F/FDVJaj4jcl8chG3

Ou

apprise -vv -t "Titre du Message de Test" -b "Corps du Message de Test" \
   twitter://testaccount@T1JJ3T3L2/A1BRTD4JD/TIiajkdnlazkcOXrIdevi7F/FDVJaj4jcl8chG3