Comment fonctionne la limite de 250 posts par jour de l'API Threads

Qu'est-ce que la limite de 250 posts par jour de l'API Threads ?

Meta applique la limite de 250 posts par jour de l'API Threads à l'étape de publication, un profil Threads peut donc transformer 250 conteneurs média en posts en ligne sur n'importe quelle tranche glissante de 24 heures. La phrase se trouve dans la section Rate Limiting de la présentation de Threads par Meta et dit : « Threads profiles are limited to 250 API-published posts within a 24-hour moving period. Carousels count as a single post. This limit is enforced on the POST /{threads-user-id}/threads_publish endpoint when attempting to publish a media container. »

Trois détails de ce passage décident du comportement d'une file. « API-published » restreint le comptage aux posts poussés via l'API Threads plutôt que tapés dans l'app Threads. « Moving » écarte une remise à zéro à minuit. Et nommer threads_publish comme point d'application signifie que la création de conteneurs est gratuite, puisque le compteur ne bouge qu'au moment où un conteneur devient un post.

Meta ajoute une quatrième phrase qui vise directement quiconque construit un planificateur : « We recommend that your app also enforces the publishing rate limit, especially if your app allows app users to schedule posts to be published in the future. »

Comment fonctionne la fenêtre de 24 heures ?

La fenêtre glisse, et chaque publication sort du compte 24 heures après avoir eu lieu plutôt qu'à une heure fixe. Un profil qui brûle ses 250 créneaux entre 08:00 et 09:00 le lundi récupère cette capacité entre 08:00 et 09:00 le mardi, une publication à la fois, et non d'un bloc à minuit.

Le point de terminaison de quota met un chiffre sur la fenêtre. Son objet config porte quota_duration: 86400, soit 24 heures en secondes, aux côtés de quota_total: 250. Rien dans la documentation Threads n'expose les horodatages des publications individuelles, la seule façon de savoir combien de place reste à la seconde près est donc de demander l'usage courant à Meta.

Quel point de terminaison indique le quota restant ?

GET /{threads-user-id}/threads_publishing_limit renvoie le compte propre au profil, et Meta le décrit comme le moyen « To validate that a user has not exhausted their API quota limits for publishing, reply publishing, deleting, and location search. » Deux champs couvrent la publication : quota_usage, que Meta définit comme « Threads publishing count over the last 24 hours », et config, qui contient quota_total et quota_duration.

curl -s -X GET \
"https://graph.threads.net/v1.0/<THREADS_USER_ID>/threads_publishing_limit?fields=quota_usage,config&access_token=<ACCESS_TOKEN>"

{
  "data": [
    {
      "quota_usage": 4,
      "config": {
        "quota_total": 250,
        "quota_duration": 86400
      }
    }
  ]
}

L'appel demande les permissions threads_basic et threads_content_publish. Lire quota_total au lieu de coder 250 en dur fait la différence entre une intégration qui survit à un changement de quota et une autre qui se bride en silence pendant un an après que Meta a relevé le plafond.

Quels sont les autres quotas de l'API Threads ?

Le même point de terminaison rapporte quatre budgets distincts, chacun avec sa paire de champs et son propre plafond. Chacun d'eux utilise un quota_duration de 86400 secondes.

Les réponses ont leur propre budget de 1 000, que Meta formule ainsi : « Threads profiles are limited to 1,000 replies within a 24-hour moving period. » Un bot qui répond aux commentaires dispose donc de quatre fois plus de marge qu'un bot qui publie, et brûler du quota de réponse ne touche jamais aux 250. Aucun de ces budgets n'interagit avec le plafond de 500 caractères du texte d'un post, qui s'applique à la création du conteneur plutôt qu'à la publication et qui est traité dans la limite de caractères de Threads.

Un carrousel compte-t-il pour un post ou pour vingt ?

Un carrousel compte pour une seule publication, quel que soit son contenu. Meta l'écrit deux fois : « Carousels count as a single post » sur la page de présentation, et « Publishing a carousel counts as a single post » dans le guide pas à pas des carrousels. Comme un carrousel Threads prend jusqu'à 20 enfants, un profil qui ne publie que des carrousels pleins fait passer 5 000 images et vidéos individuelles en 250 publications.

Ce rapport est le seul vrai levier disponible sur ce plafond. Dix images séparées coûtent dix des 250 créneaux. Les mêmes dix envoyées en un carrousel en coûtent un. Qui approche du plafond devrait regrouper ses médias avant de demander plus de marge, ce qui est exactement l'arithmétique derrière le plafond de 100 posts par 24 heures de l'API Instagram.

Pourquoi les deux pages de Meta formulent-elles la même limite différemment ?

Le nombre concorde d'une page à l'autre, la formulation non. La page de présentation dit « 250 API-published posts within a 24-hour moving period ». Le guide des carrousels, dans une note au-dessus de l'étape 3, dit « Profiles are limited to 250 published posts within a 24-hour period. »

La seconde version laisse tomber « API- » et laisse tomber « moving ». Lue au pied de la lettre, elle couvrirait les posts créés à la main dans l'app et repartirait de zéro sur une horloge fixe. Meta ne réconcilie jamais les deux, et seule la page de présentation porte le détail d'application qui nomme threads_publish, c'est donc elle qui énonce la règle le plus complètement. Traitez la phrase la plus courte comme un raccourci et non comme une seconde politique.

Quelle erreur Threads renvoie-t-il quand le quota est épuisé ?

Meta ne documente aucun code d'erreur pour le dépassement du quota de publication. L'index de l'API Reference de Threads liste neuf pages de points de terminaison et aucune page de codes d'erreur, et la page de dépannage ne couvre que les issues de conteneur : les valeurs de status EXPIRED, ERROR, FINISHED, IN_PROGRESS et PUBLISHED, plus des valeurs vidéo d'error_message comme FAILED_DOWNLOADING_VIDEO et INVALID_ASPEC_RATIO.

La seule chaîne d'échec à la publication que Meta documente n'a rien à voir avec le volume. À partir du 22 décembre 2025, un post portant plus de cinq liens échoue à l'étape du conteneur avec THREADS_API__LINK_LIMIT_EXCEEDED. Il n'existe aucune constante équivalente pour les 250.

Cette absence est la raison pour laquelle Meta demande aux apps d'appliquer la limite elles-mêmes. Du code écrit contre une réponse d'échec non documentée est une supposition ; du code qui lit quota_usage avant de publier consulte le compteur que Meta consulte aussi.

En quoi la limite de débit par app diffère-t-elle des 250 ?

Les 250 sont un budget de publication au niveau du profil. À part cela, chaque appel à l'API Threads est décompté à l'app appelante, et Meta lui donne une formule plutôt qu'une constante : Calls within 24 hours = 4800 * Number of Impressions, où les impressions sont « the number of times any content from the app user's Threads account has entered a person's screen within the last 24 hours ». La valeur minimale des impressions est 10, le plancher est donc de 48 000 appels par couple app et utilisateur.

Deux budgets de CPU l'accompagnent, 720000 * number_of_impressions pour le temps CPU total et 2880000 * Number of Impressions pour le temps total. La même forme fondée sur les impressions régit la limite de débit de 4800 impressions de l'API Instagram, ce qui n'a rien de surprenant puisque les deux tournent sur l'infrastructure Meta.

Un profil peut donc atteindre 250 publications tout en restant très loin de son budget d'appels, puisque interroger le statut d'un conteneur, lire des insights et récupérer des réponses dépensent des appels sans dépenser de publications.

Que signifie ce plafond pour une file de planification ?

Les 250 appartiennent à Threads, et tout outil qui publie via l'API officielle travaille à l'intérieur. Aucun planificateur ne relève un quota de plateforme, le travail porte donc sur la forme de la file : regrouper les médias en carrousels, étaler un lancement sur plusieurs jours, et lire quota_usage avant qu'un lot ne parte plutôt qu'après l'échec d'une publication.

Le conseil de Meta pointe dans la même direction, puisqu'il demande aux apps qui laissent programmer des posts d'appliquer localement la limite de publication. La mécanique de mise en file d'un post Threads est traitée dans comment programmer des posts Threads. Voir une semaine d'un coup est ce qui empêche de programmer une rafale, et c'est le travail d'un calendrier de contenu ; pour qui charge un mois en une seule séance, c'est dans la planification en masse que l'étalement se décide. AdaptlyPost publie sur Threads via l'API officielle, la même fenêtre de 250 posts s'applique donc ; la page outil de planification Threads explique comment fonctionne cette connexion.

Questions fréquentes

Les posts créés dans l'app Threads comptent-ils dans les 250 ?

La phrase de la page de présentation de Meta limite les profils à 250 « API-published posts », ce qui désigne les posts créés via l'API Threads. La page carrousel laisse tomber le préfixe « API- » et dit « 250 published posts », et Meta ne dit jamais quelle lecture fait foi. Interrogez GET /{threads-user-id}/threads_publishing_limit quand le volume de publication manuelle est assez élevé pour compter, puisque ce point de terminaison rapporte ce que Meta compte réellement.

Les réponses comptent-elles dans le quota de 250 posts ?

Non. Les réponses ont un budget distinct de 1 000 sur une période mobile de 24 heures, rapporté par les champs reply_quota_usage et reply_config du même point de terminaison. Publier une réponse ne réduit jamais les 250 disponibles pour les posts.

Quand la fenêtre de 24 heures se réinitialise-t-elle ?

Jamais, puisque Meta parle d'une « 24-hour moving period ». Les publications individuelles sortent du compte une à une, 24 heures après chacune. Le champ quota_duration dit la même chose en chiffres, sous la forme de 86400 secondes.

Combien d'images un profil peut-il publier par jour via l'API Threads ?

Jusqu'à 5 000, si chaque publication est un carrousel plein. Meta plafonne un carrousel à 20 enfants et le compte pour un seul post, 250 publications portent donc 250 fois 20 pièces de média. Publier des images seules plafonne le même profil à 250 images.

Créer un conteneur média consomme-t-il du quota ?

Meta indique que la limite « is enforced on the POST /{threads-user-id}/threads_publish endpoint when attempting to publish a media container », ce qui place le comptage sur l'appel de publication. Les conteneurs ont bien leur propre horloge : un conteneur non publié renvoie EXPIRED, décrit comme « The container was not published within 24 hours and has expired. »

Où la limite de 250 posts est-elle documentée ?

Sur la page de présentation de Threads de Meta à developers.facebook.com/documentation/threads/overview, sous Rate Limiting, dans la sous-section Posts. Le guide des carrousels à developers.facebook.com/documentation/threads/posts répète le nombre dans une note au-dessus de l'étape 3, et le point de terminaison de quota qui le rapporte est documenté à la fois sur la page de dépannage et dans la référence User.

La limite de 250 s'applique-t-elle au profil Threads ou à l'app ?

Les 250 forment un quota au niveau du profil, rattaché au compte Threads lui-même. Une limite de débit distincte s'applique en parallèle à chaque app, calculée à partir des impressions plutôt qu'avec un chiffre fixe, si bien qu'un profil peut atteindre ses 250 publications pendant que l'app connectée dispose encore d'une large marge d'appels.

Un développeur peut-il demander à Meta de relever le plafond de 250 ?

La documentation de Meta cite le chiffre 250 sur la page de présentation et dans le guide des carrousels, sans jamais décrire de moyen de demander un plafond plus élevé. Le seul levier documenté consiste à regrouper les médias en carrousels, puisqu'un carrousel compte comme un seul post quel que soit le nombre de ses 20 enfants possibles. Lire quota_total plutôt que coder en dur la valeur 250 est la seule précaution que Meta recommande pour le jour où ce chiffre changera.

Que doit faire une file de planification quand un lot dépasserait le quota de 250 ?

Meta ne documente aucun code d'erreur pour le dépassement du quota de publication, donc un outil qui attend d'attraper un échec n'a rien de fiable à intercepter. Meta recommande lui-même de vérifier quota_usage avant de lancer un lot et de retenir les posts localement, exactement ce qu'il demande à toute app permettant de planifier des publications futures.

La limite de 250 posts de Threads est-elle la même que celle d'Instagram ?

Les chiffres diffèrent. Les profils Threads ont droit à 250 posts publiés via l'API dans une fenêtre glissante de 24 heures, tandis que le plafond comparable de l'API Instagram est de 100 posts par 24 heures. Les deux limites tournent sur la même infrastructure Meta et s'accompagnent chacune d'une limite par app fondée sur la même formule basée sur les impressions.