Meta fixe la limite de taux de l'API Instagram à 4800 fois vos impressions

Qu'est-ce que la limite de taux de l'API Instagram ?

Une seule formule définit la limite de taux de l'API Instagram, et Meta l'imprime sur une ligne unique à la fois dans la référence de limitation de taux de la Graph API et dans l'aperçu d'Instagram Platform : Calls within 24 hours = 4800 * Number of Impressions.

La phrase qui l'entoure compte autant que la formule. Meta écrit : « Calls to the Instagram Platform endpoints, excluding messaging, are counted against the calling app's call count. An app's call count is unique for each app and app user pair, and is the number of calls the app has made in a rolling 24 hour window. »

Trois contraintes se cachent dans cette phrase. Le compteur appartient à l'app, pas au compte. Il est rattaché à un couple app et utilisateur d'app, donc un client chargé ne peut pas affamer un client calme. Et la fenêtre glisse, donc rien ne se réinitialise à minuit. Les appels sortent un par un, 24 heures après avoir été passés.

Instagram Platform relève de la catégorie Business Use Case de Meta plutôt que de l'ancienne catégorie Platform Rate Limits. Les requêtes Marketing API et Instagram sont soumises aux limites Business Use Case ; les requêtes Graph API ordinaires sont soumises aux limites Platform. Quand les deux pourraient s'appliquer, Meta tranche en une ligne : « If both Platform and Business Use Case rate limits can be applied to a request, BUC rate limits will be applied. »

À quoi s'applique le multiplicateur 4800 ?

Aux impressions, et Meta définit le mot étroitement : « The Number of Impressions is the number of times any content from the app user's Instagram professional account has entered a person's screen within the last 24 hours. »

Lisez cela comme un décompte d'écrans, pas d'abonnés, pas de posts et pas de couverture. Il compte des apparitions, donc une personne qui fait défiler quatre de vos posts en apporte quatre. Il couvre « any content » du compte, donc de vieux posts qui ramènent du trafic comptent autant que celui de ce matin. Et il se mesure sur les mêmes 24 heures glissantes que les appels qu'il finance, ce qui fait bouger l'allocation en continu plutôt que par paliers.

Cela produit un budget qui monte avec l'attention. Un compte dont les posts sont entrés 50 000 fois sur des écrans au cours de la journée écoulée finance 240 000 000 appels, un chiffre qu'aucun workflow de publication n'approche. La formule ne mord qu'en bas de l'échelle, parce que Meta ne publie aucun plancher : 4800 multiplié par zéro impression fait zéro appel, et nulle part dans la référence de limitation de taux Meta n'énonce d'allocation minimale pour un compte que personne n'a vu.

La même structure apparaît ailleurs dans le tableau de Meta. Les appels à la Pages API faits avec un token de Page ou d'utilisateur système utilisent Calls within 24 hours = 4800 * Number of Engaged Users, et LeadGen utilise Calls within 24 hours = 4800 * Leads Generated. Le multiplicateur 4800 est le chiffre maison de Meta pour un business use case de 24 heures ; seul ce qui est multiplié change.

Comment lire l'en-tête X-Business-Use-Case-Usage ?

Meta renvoie l'usage dans un en-tête de réponse plutôt que dans le corps : « All API responses made by your app that are rate limited using the BUC logic include an X-Business-Use-Case-Usage HTTP header with a JSON-formatted string that describes current application rate limit usage. This header can return up to 32 objects in one call. »

La valeur de l'en-tête est un objet JSON indexé par identifiant d'entreprise, et chaque entrée porte ces champs.

Champ	Ce que Meta dit qu'il contient
business-id	L'identifiant de l'entreprise associée au token qui effectue les appels à l'API
call_count	Un nombre entier qui exprime le pourcentage d'appels autorisés effectués par votre app
total_cputime	Un nombre entier qui exprime le pourcentage du temps CPU alloué au traitement des requêtes
total_time	Un nombre entier qui exprime le pourcentage du temps total alloué au traitement des requêtes
estimated_time_to_regain_access	Le temps, en minutes, avant que les appels ne soient plus limités
type	Le type de limite appliquée, parmi ads_insights, ads_management, custom_audience, instagram, leadgen, messenger ou pages

Pour du travail Instagram, le champ sur lequel filtrer est type, et la valeur à retenir est instagram. Une app qui touche aussi aux Pages ou aux Ads reçoit plusieurs objets dans le même en-tête, et lire le mauvais vous renseigne sur le mauvais budget.

Chacun des trois chiffres d'usage est un pourcentage, pas un décompte. call_count à 62 signifie que 62 pour cent de l'allocation sont dépensés, et Meta ne vous donne jamais le dénominateur, parce que le dénominateur est ce chiffre d'impressions recalculé en continu. Aucun endpoint ne renvoie votre plafond d'appels courant sous forme d'entier.

L'en-tête n'apparaît pas non plus sur chaque réponse. Meta formule que les statistiques d'usage en temps réel sont « included with most API responses once enough calls have been made to an endpoint. » Traitez un en-tête absent comme une absence d'information plutôt que comme un usage nul.

Pourquoi l'en-tête parle-t-il d'une heure quand la formule parle de 24 heures ?

Parce que les deux pages de Meta se contredisent, et la contradiction est en ligne sur le même document. La section Instagram énonce une « rolling 24 hour window. » Le tableau de l'en-tête, quelques écrans plus bas, définit call_count comme « A whole number expressing the percentage of allowed calls made by your app over a rolling one hour period. »

Les deux phrases décrivent le même champ sur le même en-tête pour la même API. L'une des deux est fausse pour Instagram. La formulation en une heure correspond à la section Platform Rate Limits plus haut sur la page, où les appels au niveau de l'app sont bien mesurés à l'heure, ce qui est l'origine la plus probable de l'écart.

Rien dans la documentation ne tranche, alors prévoyez la fenêtre la plus longue. Si vous supposez que le compteur se vide en une heure et qu'il se vide en réalité en 24, vous relancez contre un mur. Si vous supposez 24 et qu'il se vide en une heure, vous avez attendu plus longtemps que nécessaire. Une seule de ces deux erreurs casse un calendrier de publication.

Un second trou publié se trouve dans les tables d'erreurs. La liste des erreurs Business Use Case de Meta nomme l'error code 80002 pour le type Instagram, sans sous-code. La référence des codes d'erreur d'Instagram Platform, la page que vous liriez réellement en déboguant une publication, ne liste 80002 nulle part. Faites l'association vous-même.

Que se passe-t-il quand call_count atteint 100 ?

Les requêtes échouent avec un code d'erreur dédié. Meta écrit : « When your app reaches its Business Use Case rate limit, subsequent requests made by your app will fail and the API will respond with an error code. » Pour le type Instagram, ce code est 80002.

Le temps CPU et le temps d'horloge sont bridés séparément du volume d'appels. Meta répète les deux mêmes lignes sous chaque business use case : « When total_cputime reaches 100, calls may be throttled » et « When total_time reaches 100, calls may be throttled. » Il suffit que l'un des trois atteigne 100. Un petit nombre de requêtes lourdes peut épuiser total_cputime alors que call_count en est encore à un chiffre.

Une fois bridé, estimated_time_to_regain_access porte l'attente en minutes, et l'instruction qui suit est celle qui compte : « When the limit has been reached, stop making API calls. Continuing to make calls will continue to increase your call count, which will increase the time before calls will be successful again. »

Relancer allonge le blocage. C'est assez inhabituel pour mériter d'être intégré à la conception, parce qu'un backoff exponentiel par défaut envoie quand même des requêtes, et chacune d'elles prolonge la peine. Le bon comportement sur 80002 est de garer la file jusqu'à ce que l'en-tête dise autre chose. La même discipline paie sur le quota de publication quotidien, un plafond distinct avec sa propre erreur.

Le reste des conseils de Meta porte sur l'étalement plutôt que sur le volume : « Spread out queries evenly to avoid traffic spikes » et « Use filters to limit the data response size and avoid calls that request overlapping data. » Il existe aussi une règle de comptage qui piège ceux qui groupent des identifiants. Meta énonce que « each ID counts as one API call », et le démontre : trois requêtes séparées à un identifiant comptent pour trois appels, et une requête unique avec ids=4,5,6 compte aussi pour trois.

Deux réactions à l'erreur 80002

Arrêter la file

• call_count cesse d'augmenter
• estimated_time_to_regain_access décompte le temps restant
• les appels refonctionnent une fois l'attente terminée

Continuer à réessayer

• chaque nouvelle tentative fait grimper call_count
• estimated_time_to_regain_access augmente
• l'attente avant que les appels refonctionnent s'allonge

Quels endpoints Instagram échappent à cette limite ?

Deux familles, et Meta les nomme explicitement.

Surface	Limite applicable
Publication, médias, insights, commentaires	4800 * Number of Impressions par 24 heures
Business Discovery, Hashtag Search	Platform Rate Limits, pas Business Use Case
Conversations API	2 appels par seconde par compte professionnel
Send API, texte et liens	100 appels par seconde par compte professionnel
Send API, audio ou vidéo	10 appels par seconde par compte professionnel
Private Replies, commentaires en direct	100 appels par seconde par compte professionnel
Private Replies, posts et reels	750 appels par heure par compte professionnel

La messagerie est entièrement sortie de la formule des impressions et tourne sur des plafonds à la seconde et à l'heure. Business Discovery et Hashtag Search retombent sur les Platform Rate Limits, où la formule au niveau de l'app est Calls within one hour = 200 * Number of Users.

La limite de taux n'est pas non plus le quota de publication. Ce sont deux systèmes distincts avec des erreurs distinctes, et les confondre gaspille du temps de débogage : une publication bloquée par le volume renvoie 80002, tandis qu'une publication bloquée par le quota de publication de contenu renvoie le code 9, sous-code 2207042. D'autres réseaux se divisent de la même façon, que ce soit les plafonds de requêtes que Bluesky publie par endpoint ou le budget quotidien d'unités que YouTube mesure et vous laisse demander à relever.

Questions fréquentes

Quelle est la formule de la limite de taux de l'API Instagram ?

Calls within 24 hours = 4800 * Number of Impressions. Meta la publie sur la référence de limitation de taux de la Graph API et la répète sur l'aperçu d'Instagram Platform.

Qu'est-ce qui compte comme impression dans la limite de taux d'Instagram ?

Meta la définit comme « the number of times any content from the app user's Instagram professional account has entered a person's screen within the last 24 hours. » Elle compte les apparitions de n'importe quel contenu, pas les abonnés et pas les posts.

Quel code d'erreur signale que la limite de taux de l'API Instagram est atteinte ?

Le code d'erreur 80002. Meta le liste face au type business use case Instagram sans sous-code, et ne le répète pas dans la référence des codes d'erreur d'Instagram Platform.

Comment vérifier l'usage courant de la limite de taux de l'API Instagram ?

Lisez l'en-tête de réponse X-Business-Use-Case-Usage, trouvez l'objet dont le type vaut instagram, et regardez call_count, total_cputime et total_time. Les trois sont des pourcentages de l'allocation.

Relancer après une erreur de limite de taux aggrave-t-il la situation ?

Oui. Meta écrit que continuer à passer des appels « will continue to increase your call count, which will increase the time before calls will be successful again. » Arrêtez la file et lisez estimated_time_to_regain_access.

Les endpoints de messagerie Instagram sont-ils couverts par la formule des 4800 ?

Non. Meta exclut la messagerie de la formule des impressions et publie à la place des plafonds à la seconde et à l'heure pour les API Conversations, Send et Private Replies.

La limite de taux de l'API Instagram se réinitialise-t-elle à une heure fixe chaque jour ?

Elle ne se réinitialise ni à minuit ni à une autre heure fixe. Meta compte les appels sur une fenêtre glissante de 24 heures, si bien que chaque appel sort du compte exactement 24 heures après avoir été effectué. Le quota disponible évolue en continu plutôt que de retomber à zéro selon un horaire.

Le compteur d'appels de l'API Instagram est-il partagé entre toutes les apps connectées à mon compte ?

Chaque app tient son propre compte. Meta rattache le compteur d'appels à une seule paire app et utilisateur de l'app, si bien qu'une app très active ne peut pas épuiser le quota d'une autre app qui accède au même compte.

Quelle est la différence entre la limite de taux de l'API Instagram et le quota de publication quotidien ?

Ce sont deux systèmes distincts avec des erreurs distinctes. La limite de taux décrite ici bloque avec le code d'erreur 80002 quand call_count, total_cputime ou total_time atteint 100. Le quota de publication quotidien est un plafond différent et échoue avec le code 9, sous-code 2207042, donc un blocage de l'un n'explique jamais un blocage de l'autre.

Les appels à Business Discovery et Hashtag Search comptent-ils dans la formule des 4800 ?

Ils en sont exclus. Ces deux endpoints relèvent de l'ancienne catégorie Platform Rate Limits de Meta plutôt que de Business Use Case, où la formule appliquée est 200 fois le nombre d'utilisateurs par heure au lieu de 4800 fois les impressions.