La plateforme développeur de X tarife désormais l’API par requête plutôt que par palier d’abonnement. La création de publications est facturée par appel, et POST /2/tweets est limité à 100 requêtes par utilisateur par tranche de 15 minutes et 10 000 par application par 24 heures. Si vous hésitez à construire directement dessus, ces deux faits déterminent l’essentiel de votre architecture.
Combien coûte réellement l’API X ?
La page de tarification officielle décrit un modèle de crédits, pas des plans nommés. Vous achetez des crédits, fixez une limite de dépense, et chaque appel déduit du solde.
| Opération | Prix indiqué |
|---|---|
| Création de publication | 0,015 $ par requête |
| Publication contenant une URL | 0,200 $ par requête |
| Publication (invoquée) | 0,010 $ par requête |
| DM et interactions utilisateur | 0,015 $ par requête |
| Suppression d’interactions | 0,010 $ par requête |
| Lecture : publications | 0,005 $ par ressource |
| Lecture : utilisateurs, DM, abonnements/abonnés | 0,010 $ par ressource |
| Lecture : likes, sourdines, blocages | 0,001 $ par ressource |
| Lectures propres (vos propres données) | 0,001 $ par ressource |
Deux détails comptent plus que les prix unitaires. Une publication contenant une URL coûte plus de 13 fois une publication simple, ce qui est une ligne budgétaire significative si vous publiez des liens pour gagner votre vie. Et les plans à l’usage sont plafonnés à 3 millions de lectures de publications par cycle de facturation mensuel, donc les produits à forte consommation en lecture atteignent un plafond qu’aucun achat de crédits supplémentaires ne peut lever.
Les ressources sont dédupliquées sur une fenêtre de 24 heures UTC, donc demander la même ressource deux fois dans la journée n’est facturé qu’une fois.
Remarque : les chiffres ici ont été vérifiés par rapport à docs.x.com/x-api/getting-started/pricing en date de septembre 2026. Les plateformes modifient ces informations sans préavis.
Ce que nous n’avons pas pu vérifier. D’anciens paliers Free, Basic et Pro avec des plafonds mensuels de publications sont largement cités sur le web. Nous n’avons trouvé aucune page officielle les listant : les pages actuelles de tarification et de présentation décrivent un modèle à l’usage sans paliers nommés, et l’URL du palier renvoie une erreur 404. Nous ne reprenons pas des chiffres tiers. Consultez la Developer Console pour les tarifs applicables à votre compte.
Que peut publier l’API X, et que ne peut-elle pas ?
POST /2/tweets accepte text, ainsi que, en option, media.media_ids, reply, poll, geo, reply_settings et quelques indicateurs comme made_with_ai et paid_partnership.
Les médias ne font pas partie de cet appel. Vous les téléversez séparément via les points de terminaison de téléversement fragmenté, puis passez le media_id obtenu. Une publication accepte jusqu’à 4 photos, 1 GIF animé, ou 1 vidéo.
Les limites à connaître avant de vous engager :
quote_tweet_idest réservé à Enterprise. La republication citée n’est pas disponible sur le point de terminaison général.- Les plafonds vidéo dépendent du compte publiant, pas de votre application. Les comptes standard sont plafonnés à 20 minutes et 8 Go ; les comptes X Premium et vérifiés à 125 minutes et 16 Go. Votre outil de téléversement doit gérer les deux cas, car la limite appartient à l’utilisateur au nom duquel vous publiez.
- Les sondages sont contraints. 2 à 4 options, durée entre 5 et 10 080 minutes.
- La référence de création n’indique pas de limite de caractères. Nous n’avons pas pu en vérifier une sur cette page. Voir l’article sur la limite de caractères X pour ce que le produit applique réellement.
Remarque : les chiffres ici ont été vérifiés par rapport à docs.x.com/x-api/posts/creation-of-a-post en date de septembre 2026. Les plateformes modifient ces informations sans préavis.
Quel est le modèle d’authentification, en termes simples ?
Deux modes, et la publication ne fonctionne que dans l’un des deux.
Jeton porteur uniquement pour l’application. Un identifiant unique représentant votre application. Il lit les données publiques. Il ne peut pas publier, car il n’y a pas d’utilisateur au nom duquel publier.
OAuth 2.0 Authorization Code avec PKCE, contexte utilisateur. L’utilisateur est envoyé vers la boîte de dialogue d’autorisation de X, revient avec un code, et vous l’échangez contre un jeton d’accès. La publication nécessite le scope tweet.write, en plus de tweet.read et users.read. Si vous voulez continuer à publier après l’expiration du jeton d’accès, vous devez demander offline.access au moment de l’autorisation, ce qui déclenche l’émission d’un jeton de rafraîchissement.
Ce dernier point est celui qui pose problème. offline.access doit être demandé explicitement à chaque autorisation. L’omettre oblige chaque utilisateur à se réautoriser de façon interactive, ce qui est fatal pour un programmateur qui publie à 3 h du matin. La documentation n’indique pas la durée de vie du jeton d’accès, traitez-la donc comme courte et rafraîchissez-le de façon proactive.
Quelles sont les limites de débit sur la publication ?
| Point de terminaison | Par utilisateur | Par application |
|---|---|---|
POST /2/tweets | 100 par 15 minutes | 10 000 par 24 heures |
Chaque réponse porte x-rate-limit-limit, x-rate-limit-remaining et x-rate-limit-reset (un horodatage Unix). Lisez-les plutôt que de compter vos propres appels, car votre compteur et celui de X divergeront dès qu’une nouvelle tentative se produit.
La documentation précise explicitement que les limites de débit et la facturation sont des sujets distincts. Rester sous la limite de débit ne plafonne pas votre dépense, et fixer une limite de dépense ne vous empêche pas de recevoir des erreurs 429. Il vous faut les deux contrôles.
Remarque : les chiffres ici ont été vérifiés par rapport à docs.x.com/x-api/fundamentals/rate-limits en date de septembre 2026. Les plateformes modifient ces informations sans préavis.
Qu’est-ce qui vous coûtera réellement trois semaines ?
Pas l’appel de publication. L’appel de publication, c’est l’affaire d’un après-midi.
Le rafraîchissement de jeton. Demander offline.access, stocker les jetons de rafraîchissement de façon chiffrée, gérer la rotation, et prévoir un chemin de reconnexion pour les utilisateurs dont le rafraîchissement échoue. C’est un traitement de fond avec ses propres modes de défaillance, pas une simple fonction.
Le téléversement média fragmenté. INIT, APPEND, FINALIZE, puis interrogation du statut de traitement avant que le media_id ne soit utilisable dans une publication. Les vidéos échouent au transcodage, et elles échouent après que votre téléversement a renvoyé 200.
Les plafonds vidéo par compte. 20 minutes contre 125 minutes est une branche d’exécution basée sur le compte auquel vous publiez, et vous ne pouvez pas le savoir à partir des seuls identifiants de votre application.
La comptabilité des coûts. Un prix par requête signifie que quelqu’un doit attribuer la dépense aux clients, sous peine de découvrir la surtaxe URL sur une facture.
La gestion des erreurs 429 qui n’est pas une simple pause. La fenêtre par utilisateur est de 15 minutes. Une boucle de nouvelle tentative naïve transforme une publication limitée en débit en un traitement bloqué.
En résumé
- La tarification est à l’usage, en crédits. La création de publication coûte 0,015 $ par requête ; une publication avec une URL coûte 0,200 $.
- Les lectures en mode à l’usage sont plafonnées à 3 millions de publications par cycle de facturation mensuel.
POST /2/tweetsautorise 100 par utilisateur par 15 minutes, 10 000 par application par 24 heures.- La publication nécessite un contexte utilisateur OAuth 2.0 PKCE avec
tweet.write, plusoffline.accesssi vous voulez des jetons de rafraîchissement. - Les médias se téléversent séparément : 4 photos, 1 GIF, ou 1 vidéo. La republication citée est réservée à Enterprise.
- Les paliers nommés Free/Basic/Pro n’ont pas pu être vérifiés sur une page officielle en septembre 2026.
Le faire une fois plutôt qu’une fois par plateforme
Le travail décrit ci-dessus est réel, et il est propre à X. LinkedIn nécessite deux applications distinctes avec des scopes différents. TikTok exige de passer un audit de la Content Posting API. Threads utilise une séquence conteneur-puis-publication avec un cycle de rafraîchissement de jeton de 60 jours. Rien de tout cela ne se transpose.
BulkPublish expose une seule API REST sur 15 plateformes : Facebook, Instagram, TikTok, YouTube, X, Bluesky, Threads, Pinterest, LinkedIn, Google Business Profile, Mastodon, Discord, Telegram, Tumblr et Snapchat. Un seul modèle d’authentification, un seul pipeline média, un seul objet publication, avec le rafraîchissement de jeton par plateforme et l’interrogation de statut asynchrone gérés en coulisses. La documentation développeur et la référence de l’API REST couvrent les points de terminaison.