Apps développeur

​

Aperçu

Si vous avez déjà des Apps, vous pouvez les consulter, les modifier ou les supprimer via la page App du portail développeurs.

L’accès à la X API et à la X Ads API nécessite un ensemble d’informations d’authentification, également appelées clés et jetons, que vous devez transmettre avec chaque requête. Ces identifiants peuvent prendre différentes formes selon le type d’authentification requis par l’endpoint que vous utilisez.

Voici les différents identifiants que vous pouvez générer dans votre App et comment les utiliser :

• API Key and Secret : En pratique, le nom d’utilisateur et le mot de passe de votre App. Vous les utiliserez pour authentifier les requêtes qui nécessitent le Contexte utilisateur OAuth 1.0a, ou pour générer d’autres jetons tels que des Access Tokens utilisateur ou l’App Access Token.

• Access Token and Secret : En général, les Access Tokens représentent l’utilisateur pour le compte duquel vous effectuez la requête. Ceux que vous pouvez générer via le portail développeurs représentent l’utilisateur propriétaire de l’App. Vous les utiliserez pour authentifier les requêtes qui nécessitent le Contexte utilisateur OAuth 1.0a. Si vous souhaitez effectuer des requêtes au nom d’un autre utilisateur, vous devrez utiliser le flux OAuth à 3 étapes afin qu’il vous autorise.

• Client ID and Client Secret : Ces identifiants sont utilisés pour obtenir un Access Token utilisateur avec l’authentification OAuth 2.0. À l’instar d’OAuth 1.0a, les Access Tokens utilisateur servent à authentifier des requêtes qui fournissent des informations privées de compte utilisateur ou qui effectuent des actions au nom d’un autre compte, mais avec une portée fine pour un meilleur contrôle sur les accès de l’application cliente au compte utilisateur.

• App only Access Token : Vous utiliserez ce jeton lors de requêtes vers des endpoints qui renvoient des informations publiquement disponibles sur X.

En plus de générer les clés et jetons nécessaires pour effectuer des requêtes à la X API, vous pourrez également définir des autorisations d’accès, documenter le cas d’usage ou l’objectif de l’App, définir une URL de rappel et modifier d’autres paramètres liés à votre environnement de développement d’App depuis le tableau de bord de gestion.

​

Apps et Projects

Vous pouvez utiliser des Apps et des Projects pour organiser votre travail sur la X Developer Platform par cas d’usage. Chaque Project peut inclure une App avec l’offre Free X API, jusqu’à deux Apps avec l’offre Basic et jusqu’à trois Apps avec l’offre Pro.

Si vous souhaitez accéder aux nouveaux endpoints de la X API v2, vous devrez utiliser des clés et des jetons d’une App associée à un Project.

Si vous avez des Apps créées avant le lancement des Projects, elles seront visibles dans la section intitulée « Standalone Apps ». Les Standalone Apps sont des Apps en dehors de la structure Project. Si vous rattachez une Standalone App à un Project, elle pourra ensuite effectuer des requêtes vers les endpoints v2.

​

Tableau de bord du portail développeurs

Vous pouvez accéder au tableau de bord pour gérer les Apps associées à votre compte. Pour en savoir plus, veuillez consulter notre page de documentation sur le portail développeurs. Le tableau de bord permet aux développeurs d’effectuer rapidement et facilement les tâches suivantes :

• Afficher vos Apps autonomes existantes et leur App ID associé.
• Créer un nouveau Project, une App ou une App autonome.
• Supprimer un Project ou une App inutilisé(e).
• Examiner ou mettre à jour les paramètres d’une App spécifique, y compris le nom, la description, le site web, l’URL de callback et les permissions.
• Régénérer des identifiants spécifiques à l’App, comme la Clé d’API et le Secret, l’App Access Token et les Access Tokens utilisateur du propriétaire de l’App.

​

Inscription pour accéder

Si vous avez déjà des X Apps, vous pouvez afficher et modifier vos Apps via le tableau de bord App de X si vous êtes connecté à votre compte X sur developer.x.com. Notez que vous n’aurez pas besoin de créer un compte pour gérer toutes les Apps précédemment créées sur developer.x.com.

Si vous devez créer une nouvelle X App, vous devez d’abord vous être inscrit pour obtenir un compte développeur. Si vous êtes membre d’un compte d’équipe, un rôle d’administrateur doit vous être attribué pour créer une nouvelle App.

​

Étiquetage de compte automatisé pour les bots

Vous pouvez ajouter le libellé Compte automatisé à vos comptes bot pour indiquer aux utilisateurs sur X que votre bot est un compte automatisé. Ces bots effectuent des actions programmées via la X API. Lorsque vous ajoutez le libellé Compte automatisé à votre bot, vous renforcez la confiance de votre audience, légitimez votre compte et vous vous distinguez des bots indésirables. Cela aide les personnes sur X à mieux comprendre l’objectif de votre compte lorsqu’elles interagissent avec votre bot.

Pour ajouter un libellé à votre compte bot, suivez ces étapes :

1. Accédez aux paramètres de votre compte
2. Sélectionnez « Votre compte »
3. Sélectionnez « Automatisation »
4. Sélectionnez « Gestion du compte »
5. Sélectionnez ensuite le compte X qui exécute votre compte bot
6. Saisissez votre mot de passe pour vous connecter
7. Enfin, vous devriez voir une confirmation indiquant que le libellé a été appliqué à votre compte.

---

​

Gestion des Apps

​

Introduction

Le tableau de bord X App permet aux développeurs d’effectuer rapidement et facilement les tâches suivantes :

• Afficher vos Apps et Projects existants ainsi que leur App ID associé.
• Créer un nouveau Project ou une App autonome.
• Supprimer un Project, une App ou une App autonome.
• Ouvrir les paramètres d’une App spécifique en cliquant sur les paramètres de l’App. Dans ces paramètres, vous pouvez consulter les détails de l’App, ses clés et jetons, ainsi que ses autorisations.
• Mettre à jour les paramètres d’authentification utilisateur de votre App pour utiliser OAuth 1.0a ou OAuth 2.0.

Remarque :

Toutes les clés et tous les jetons d’App ne sont plus visibles dans le portail développeurs et doivent être enregistrés en lieu sûr dès leur génération. Nous recommandons d’utiliser un gestionnaire de mots de passe pour stocker vos clés et jetons.

Vous pouvez afficher un indice de Clé d’API pour vous aider à faire correspondre votre identifiant d’API à l’App correspondante.

​

Paramètres de l’App

​

Détails de l’App

Ici, vous pouvez modifier l’icône de l’App, le nom de l’App, la description de l’App, l’URL de votre site web, les callback URLs/redirect URIs, l’URL des conditions d’utilisation, l’URL de la politique de confidentialité, le nom de l’organisation, l’URL de l’organisation, ainsi que l’objectif ou le cas d’usage de l’App.

OAuth 2.0 et OAuth 1.0a sont des méthodes d’authentification qui permettent aux utilisateurs de se connecter à votre App avec X. Elles permettent également à votre App d’effectuer des requêtes spécifiques au nom des utilisateurs authentifiés. Vous pouvez activer l’une ou les deux méthodes pour votre App.

Il est important de maintenir ces informations à jour. Le nom de votre App et l’URL de votre site web seront affichés comme source dans les metadata de tout Tweet créé de manière programmatique par votre application. Si vous changez le cas d’usage d’une X App, assurez-vous de le mettre à jour dans ces paramètres afin de garantir votre conformité aux Developer Terms.

Si votre application affiche une étiquette « suspended », c’est parce que votre App enfreint une ou plusieurs des developer terms de X, telles que nos automation rules. L’équipe chargée des politiques de la plateforme développeur communiquera avec les développeurs via l’adresse e‑mail configurée sur le compte X du propriétaire de l’App ; pour vérifier cette adresse e‑mail, veuillez consulter vos X account settings. Les e‑mails de notification concernant les suspensions seront envoyés à cette adresse avec un title similaire à « Application suspension notice » et contiendront des informations précises sur la marche à suivre. Pour collaborer avec l’équipe X afin de traiter les suspensions, veuillez consulter votre e‑mail pour des instructions spécifiques ou utiliser notre platform help form.

​

Clés et jetons

Dans une App au sein d’un Project ou via une App autonome, vous pouvez afficher, régénérer ou révoquer les jetons suivants :

• API Key (Consumer Key) et API Secret (Consumer Secret)
• App Access Token
• User Access Token et Access Token Secret - L’Access Token et le Secret disponibles dans le portail développeurs concernent l’utilisateur propriétaire de l’App.

Veuillez noter : si vous souhaitez effectuer des requêtes au nom d’un autre utilisateur (autrement dit, un utilisateur autre que le propriétaire de l’App), vous devrez utiliser soit le flux OAuth 1.0a à 3 étapes, soit le flux OAuth 2.0 Authorization Code with PKCE pour générer un ensemble d’Access Tokens utilisateur. Vous utiliserez ensuite ces jetons spécifiques à l’utilisateur dans votre requête à l’API.

​

Paramètres d’authentification utilisateur

Vous pouvez configurer l’authentification de votre App avec OAuth 1.0a ou OAuth 2.0. OAuth 2.0 ne peut être utilisé qu’avec la X API v2. OAuth 2.0 vous permet de choisir des étendues (scopes) fines et spécifiques qui accordent des permissions précises au nom d’un utilisateur. OAuth 1.0a peut être utilisé avec la X API v1.1 et v2 et s’appuie sur une autorisation plus large avec des étendues plus générales.

​

Autorisations application-utilisateur OAuth 1.0a

Si vous êtes le propriétaire de l’App, vous pouvez ajuster les autorisations de l’App (lecture seule, lecture et écriture, ou lecture, écriture et Messages privés). Cela détermine les ressources et événements auxquels vous avez accès via la X API (remarque : certaines ressources nécessitent une autorisation supplémentaire directement de la part de X).

Vous pouvez également activer ou désactiver, sur cette page, la capacité de vos Apps à demander les adresses e‑mail des utilisateurs (cela nécessite que des URL des Conditions d’utilisation et de la Politique de confidentialité soient renseignées sur la page « App details »).

​

Type d’App OAuth 2.0

Si vous sélectionnez OAuth 2.0 comme méthode d’authentification des utilisateurs, vous devrez choisir le type d’App que vous créez. Vos options sont Native App, Single page App, Web App, Automated App ou bot. Les Native App et Single page App sont des clients publics, et les Web App et Automated App ou bots sont des clients confidentiels.

Les clients confidentiels s’authentifient de manière sécurisée auprès du serveur d’autorisation. Ils protègent votre secret client. Les clients publics sont des applications généralement exécutées dans un navigateur ou sur un appareil mobile et ne peuvent pas utiliser vos secrets client. Si vous choisissez un type d’App qui est un client confidentiel, un secret client vous sera fourni.

---

​

Autorisations de l’App

​

Autorisations d’App OAuth 1.0a

Les autorisations d’App définissent le niveau d’accès pour l’authentification application‑utilisateur OAuth 1.0a. Les autorisations d’App se configurent par application dans les paramètres de votre X App.

Trois niveaux d’autorisation sont disponibles :

1. Lecture seule
2. Lecture et écriture
3. Lecture, écriture et accès aux Messages privés

Une autorisation supplémentaire permet de demander l’accès à l’adresse e‑mail d’un utilisateur ; elle peut être combinée avec l’un des trois niveaux ci‑dessus.

Si un niveau d’autorisation est modifié, tous les jetons utilisateur déjà émis pour cette X App doivent être révoqués et les utilisateurs doivent réautoriser l’App afin que le jeton hérite des autorisations mises à jour.

Une bonne pratique consiste à demander uniquement le niveau minimal d’accès aux données de compte dont une application ou un service a besoin.

​

Lecture seule

Ce niveau d’autorisation permet un accès en lecture aux ressources X, notamment (par exemple) les Tweets d’un utilisateur, son fil d’accueil et les informations de son profil. Il n’autorise pas la lecture des Messages privés d’un utilisateur et n’autorise la mise à jour d’aucun élément ou objet.

​

Lecture et écriture

Ce niveau d’autorisation permet un accès en lecture et en écriture aux ressources de X. En plus de l’accès en lecture, il autorise la publication de Tweets, le suivi d’utilisateurs et la mise à jour d’éléments des informations de profil d’un utilisateur. Il permet également de masquer des réponses au nom de l’utilisateur authentifié. Ce niveau d’autorisation n’accorde aucun accès aux Messages privés (lecture, écriture ou delete).

​

Lecture, écriture et accès aux Messages privés

Ce niveau d’autorisation inclut l’accès à tout ce qui précède et ajoute la capacité de lire, d’écrire et de supprimer des Messages privés au nom d’un utilisateur.

• POST /2/dm_conversations/:dm_conversation_id/messages
• POST /2/dm_conversations/
• POST /2/dm_conversations/with/:participant_id/messages
• GET /2/dm_conversations/with/:user_id/dm_events
• GET /2/dm_conversations/:dm_conversation_id/dm_events
• GET /2/dm_events

​

Détermination des autorisations

Toutes les requêtes API authentifiées renvoient un en-tête x-access-level dans la réponse HTTP. La valeur de cet en-tête indique le niveau d’autorisation actuellement en vigueur. Les valeurs possibles sont read, read-write et read-write-directmessages.

---

​

URL de rappel

Les méthodes d’authentification Contexte utilisateur OAuth 1.0a et OAuth 2.0 Autorisation par code avec PKCE permettent aux développeurs d’effectuer des requêtes au nom de différents utilisateurs X ayant suivi un flux de connexion spécifique. Actuellement, deux flux peuvent être utilisés pour permettre aux utilisateurs d’autoriser votre application :

• Flux d’autorisation OAuth 2.0 par code avec PKCE
• Flux OAuth à 3 étapes OAuth 1.0a (et, séparément, le flux Se connecter avec X)

Au fur et à mesure que les utilisateurs suivent ces flux, ils ont besoin d’une page web ou d’un emplacement vers lequel être redirigés après s’être connectés avec succès et avoir accordé l’autorisation à l’App du développeur. Cette page web ou cet emplacement de suivi est appelé URL de rappel.

Lors de la configuration de ces flux pour leurs utilisateurs potentiels, les développeurs doivent transmettre une URL de rappel avec leurs requêtes aux endpoints d’authentification qui composent les flux mentionnés précédemment. Par exemple, les développeurs utilisant le Contexte utilisateur OAuth 1.0a doivent transmettre le paramètre callback_url lorsqu’ils effectuent une requête vers l’endpoint GET oauth/request_token. De même, les développeurs utilisant OAuth 2.0 Autorisation par code avec PKCE doivent transmettre le paramètre redirect_uri avec leur requête vers l’endpoint GET oauth2/authorize.

En plus d’utiliser ces paramètres, le développeur doit également s’assurer que l’URL de rappel a été ajoutée à la liste d’autorisation des URL de rappel de son App, accessible depuis la page des paramètres de l’App sur le portail développeurs.

Si tout est correctement configuré, les développeurs seront redirigés vers l’URL de rappel après s’être connectés avec succès à X dans le cadre de ces flux.

​

Points à garder à l’esprit

Lorsque vous configurez vos URL de callback, voici quelques points à garder à l’esprit :

Encodez en HTTP vos paramètres query

Comme vous transmettez l’URL de callback en tant que paramètre query via callback_url ou redirect_uri, veillez à encoder l’URL en HTTP.

Limites des URL de callback

Il existe une limite stricte de 10 URL de callback dans le tableau de bord des X Apps. Votre URL de callback doit toujours correspondre exactement entre l’URL autorisée que vous ajoutez dans le tableau de bord des Apps et le paramètre que vous fournissez dans le flux d’autorisation.

Si vous souhaitez inclure des données propres à la requête dans l’URL de callback, vous pouvez utiliser le paramètre state pour stocker des données qui seront incluses après la redirection de l’utilisateur. Vous pouvez soit encoder les données directement dans le paramètre state, soit l’utiliser comme identifiant de session pour stocker l’état côté serveur.

N’utilisez pas localhost comme URL de callback Au lieu d’utiliser localhost, utilisez un hôte personnalisé en local ou http(s)://127.0.0.1

URL à protocole personnalisé Si vous souhaitez tirer parti du deep linking mobile, vous pouvez utiliser des URL à protocole personnalisé avec une partie chemin et une partie domaine, comme twitter://callback/path. Cependant, nous avons une liste de protocoles non autorisés à éviter. Vous pouvez consulter la liste des protocoles non autorisés ci‑dessous.

Protocoles non autorisés

vbscript	ldap
javascript	mailto
vbs	mmst
data	mmsu
mocha	msbd
keyword	rtsp
livescript	mso-offdap
ftp	snews
file	news
gopher	nntp
acrobat	outlook
callto	stssync
daap	rlogin
itpc	telnet
itms	tn3270
firefoxurl	shell
hcp	sip

​

Exemple d’erreur

Si vous utilisez une URL de rappel qui n’a pas été correctement ajoutée aux paramètres de votre App dans le portail développeurs, vous verrez le message d’erreur suivant :

OAuth 1.0a

HTTP 403 - Forbidden

{
  "errors": [
    {
      "code":415,"message":"URL de callback non approuvée pour cette App cliente. Les URL de callback approuvées peuvent être ajustées dans les paramètres de votre App."
    }
  ]
}

OU

<?xml version="1.0" encoding="UTF-8"?>
<hash>
<error>URL de callback non approuvée pour cette application cliente. Les URL de callback approuvées peuvent être ajustées dans les paramètres de votre application</error>
<request>/oauth/request_token</request>
</hash>

OAuth 2.0

HTTP 400

{
  "error": "invalid_request",
  "error_description": "La valeur transmise pour l'URI de redirection ne correspond pas à l'URI du code d'autorisation."
}

Dépannage

Si vous recevez une erreur, assurez-vous que l’URL de rappel utilisée dans vos requêtes d’authentification est encodée en HTTP et qu’elle correspond à une URL de rappel ajoutée à la allowlist de l’App dont vous utilisez les clés et jetons dans votre requête.

---