Publier sur Threads nécessite deux appels API, pas un seul : vous créez un conteneur média, puis vous le publiez. Les profils sont limités à 250 publications via l’API par 24 heures, les publications textuelles sont plafonnées à 500 caractères, et chaque permission utilisée par votre application doit passer la revue d’application de Meta avant que quiconque en dehors de votre liste de testeurs puisse se connecter.
Que peut publier l’API Threads, et que ne peut-elle pas ?
Les publications simples prennent en charge trois types de médias : TEXT, IMAGE et VIDEO. Les carrousels acceptent des éléments enfants IMAGE et VIDEO, entre 2 et 20, et un carrousel compte comme une seule publication au regard de votre limite de publication.
Les spécifications, tirées de la documentation officielle de Meta :
| Contrainte | Valeur |
|---|---|
| Longueur du texte | 500 caractères |
| Éléments du carrousel | 2 à 20 |
| Formats d’image | JPEG, PNG |
| Taille du fichier image | 8 Mo maximum |
| Largeur de l’image | 320 à 1440 pixels |
| Ratio d’aspect de l’image | 10:1 maximum |
| Conteneur vidéo | MOV ou MP4 |
| Codecs vidéo | vidéo H264 ou HEVC, audio AAC |
| Fréquence d’images vidéo | 23 à 60 IPS |
| Durée de la vidéo | 300 secondes (5 minutes) |
| Taille du fichier vidéo | 1 Go maximum |
| Débit vidéo | 100 Mbit/s vidéo, 128 kbit/s audio |
Un détail qui surprend : les émojis comptent dans les 500 caractères selon leur valeur en octets UTF-8, pas comme des caractères uniques. Une légende qui semble faire 480 caractères dans votre éditeur peut être rejetée. Si vous comptez côté client, comptez les octets pour les émojis. L’article limite de caractères Threads et le compteur de caractères Threads gratuit gèrent tous les deux ce cas.
Remarque : les chiffres de cet article ont été vérifiés par rapport à developers.facebook.com/docs/threads/posts et /docs/threads/overview en septembre 2026. Les plateformes modifient ces éléments sans préavis.
Quel est le modèle d’authentification ?
Threads fonctionne sur l’infrastructure d’application de Meta, mais avec ses propres identifiants. Vous créez une application Meta avec le cas d’usage Threads, et cette application émet un ID et un secret d’application spécifiques à Threads, distincts de ceux affichés ailleurs dans le tableau de bord. Utiliser la mauvaise paire est une erreur fréquente de la première heure.
Les portées sont granulaires :
threads_basic(requis par chaque point de terminaison)threads_content_publish(publication)threads_manage_repliesetthreads_read_repliesthreads_manage_insightsthreads_deletethreads_location_tagging
La revue d’application n’est pas facultative. Chaque permission doit être approuvée via la revue d’application, et l’application doit être publiée en production, avant que tout utilisateur non testeur puisse l’accorder. En attendant, vous ne pouvez publier que sur des profils Threads que vous avez explicitement invités comme testeurs depuis le tableau de bord de l’application, et qui ont accepté l’invitation depuis leurs paramètres Threads. La documentation de Meta n’indique pas la durée de la revue, donc nous ne devinerons pas.
Le cycle de vie du jeton que vous devez construire
C’est la partie qui devient une tâche récurrente.
- La fenêtre d’autorisation renvoie un code.
- Échangez-le contre un jeton d’accès de courte durée, valable 1 heure.
- Échangez celui-ci contre un jeton de longue durée via
GET /access_tokenavecgrant_type=th_exchange_token. Valable 60 jours. - Renouvelez via
GET /refresh_access_tokenavecgrant_type=th_refresh_token. Un jeton doit avoir au moins 24 heures et ne pas être encore expiré pour être renouvelable. Un jeton renouvelé est valable 60 jours de plus.
Un jeton qui passe 60 jours sans renouvellement expire, et l’utilisateur doit se réautoriser. Les permissions accordées par des utilisateurs d’application avec des profils privés sont valables 90 jours.
Remarque : les chiffres de cet article ont été vérifiés par rapport à developers.facebook.com/docs/threads/get-started et /get-started/long-lived-tokens en septembre 2026. Les plateformes modifient ces éléments sans préavis.
Quelle est la séquence de publication réelle ?
Pour une publication simple :
POST /{threads-user-id}/threadsavecmedia_typeet votre texte ou l’URL du média. Cela renvoie un ID de conteneur.- Attendez. Meta recommande en moyenne 30 secondes avant de publier, pour laisser le serveur terminer le traitement du média.
POST /{threads-user-id}/threads_publishavec cet ID de conteneur.
Pour un carrousel, insérez une étape : créez un conteneur par élément enfant, puis créez un conteneur de carrousel qui les référence, puis publiez ce dernier.
# 1. create the container
curl -X POST "https://graph.threads.net/v1.0/$USER_ID/threads" \
-d "media_type=IMAGE" \
-d "image_url=https://example.com/photo.jpg" \
-d "text=Shipping notes for this week." \
-d "access_token=$TOKEN"
# -> {"id":"1789..."}
# 2. wait ~30s for processing, then publish
curl -X POST "https://graph.threads.net/v1.0/$USER_ID/threads_publish" \
-d "creation_id=1789..." \
-d "access_token=$TOKEN"
Notez que les images et vidéos sont transmises par URL publique, pas envoyées en tant qu’octets. Les serveurs de Meta les récupèrent. Cela signifie que votre média doit être accessible publiquement, sans authentification, et toujours en ligne au moment de la récupération, ce qui est une exigence d’hébergement que la plupart des gens n’anticipent pas.
Quelles sont les limites de débit ?
| Action | Limite |
|---|---|
| Publications publiées | 250 par période mobile de 24 heures |
| Réponses | 1 000 par 24 heures |
| Suppressions | 100 par 24 heures |
| Recherches de localisation | 500 par 24 heures |
| Appels API généraux | 4 800 x nombre d’impressions, par 24 heures (minimum 10 impressions) |
La formule des impressions mérite d’être lue deux fois. Votre budget d’appels général évolue selon la portée réelle du profil, avec un plancher. Un profil tout neuf dispose du budget minimum.
Remarque : les chiffres de cet article ont été vérifiés par rapport à developers.facebook.com/docs/threads/overview en septembre 2026. Les plateformes modifient ces éléments sans préavis.
Qu’est-ce qui vous coûtera vraiment trois semaines ?
La revue d’application. Préparer des captures vidéo, une politique de confidentialité, un parcours de démonstration fonctionnel et une vérification d’entreprise, puis itérer sur les refus. La durée n’est pas publiée, donc prévoyez-la comme un risque de planning plutôt que comme une tâche.
La tâche de renouvellement de jeton. Les jetons de longue durée expirent en 60 jours et ne sont renouvelables qu’à partir de 24 heures. Cela implique une tâche planifiée, un stockage de jetons chiffrés, une alerte en cas d’échec du renouvellement, et un parcours de reconnexion dans votre interface.
L’échec asynchrone. Le fait que l’appel de conteneur renvoie 200 ne signifie pas que votre média est valide. C’est l’appel de publication qui révèle une vidéo défectueuse, environ 30 secondes plus tard, dans une requête différente. Votre modèle de publication a besoin d’un état processing et d’un moyen de signaler un échec survenu après que l’utilisateur a fermé l’onglet.
L’hébergement public des médias. Comme Meta récupère par URL, vous avez besoin d’URL publiques durables avec un comportement de cache raisonnable, et d’un plan pour ce qui se passe quand la récupération est limitée en débit ou bloquée par la protection anti-bot de votre CDN.
Le comptage en octets pour les émojis. Facile à corriger, coûteux à découvrir en production.
En bref
- Deux appels pour publier : créer un conteneur, attendre environ 30 secondes, le publier. Trois pour un carrousel.
- Les médias sont transmis par URL publique. Meta les récupère.
- 500 caractères. Les émojis comptent en octets UTF-8.
- 250 publications via l’API par profil et par 24 heures.
- Les jetons de courte durée durent 1 heure, ceux de longue durée 60 jours, renouvelables à partir de 24 heures.
- La revue d’application est requise par permission avant que les non-testeurs puissent se connecter. Aucune durée n’est publiée.
Programmer Threads en même temps que tout le reste
Si Threads est une plateforme parmi d’autres plutôt que le produit entier, la majeure partie du travail ci-dessus se répète par réseau, sous des formes différentes. X utilise OAuth 2.0 PKCE et des téléversements par blocs d’octets. Bluesky ne nécessite aucune revue d’application. LinkedIn nécessite deux applications distinctes : les profils personnels utilisent w_member_social, les pages d’entreprise utilisent r_organization_social, w_organization_social et rw_organization_admin, revues séparément.
BulkPublish couvre 15 plateformes derrière une seule API REST, y compris Threads, avec la séquence de conteneur, le renouvellement à 60 jours et l’interrogation de statut asynchrone gérés côté serveur. La documentation développeur et la référence de l’API REST listent les points de terminaison, et programmer des publications Threads couvre le parcours non-développeur.