Ce que le scope instagram_business_content_publish accorde vraiment

Qu'accorde instagram_business_content_publish ?

Meta définit le scope instagram_business_content_publish en une seule phrase dans la Permissions Reference : « The instagram_business_content_publish permission allows an app to create organic feed photo and video posts on behalf of a business user. »

La ligne d'usage autorisé ajoute la limite : « Manage the organic content creation process for Instagram (for example, post photos and videos) on behalf of an Instagram business account. »

Deux expressions de cette définition font l'essentiel du travail. Organic exclut tout ce qui est payant, donc le scope ne touche ni aux publicités, ni aux posts sponsorisés, ni à la promotion. On behalf of a business user signifie que la permission n'atteint que les comptes qui l'ont accordée à votre app, et Meta énonce la limite de façon générale dans la présentation de l'Instagram Platform : « a permission only allows access to data created by the app user who granted the permission. »

Le scope ne voyage jamais seul non plus. Meta lui liste une dépendance, instagram_business_basic, et cette dépendance n'est pas une formalité. Basic porte l'identité du compte, publish porte l'écriture. Demander publish sans basic laisse l'app sans aucun moyen de résoudre l'identifiant utilisateur Instagram que chaque endpoint de publication attend dans son chemin.

Quels endpoints exigent ce scope ?

Quatre, et Meta imprime la même paire de permissions dans le tableau des prérequis de chacune de leurs pages de référence.

Endpoint	Ce qu'il fait	Permissions pour Instagram Login
POST /<IG_ID>/media	Crée le conteneur de média	instagram_business_basic, instagram_business_content_publish
POST /<IG_ID>/media_publish	Publie le conteneur	instagram_business_basic, instagram_business_content_publish
GET /<IG_CONTAINER_ID>	Lit le statut du conteneur	instagram_business_basic, instagram_business_content_publish
GET /<IG_ID>/content_publishing_limit	Lit la consommation actuelle du quota	instagram_business_basic, instagram_business_content_publish

La troisième ligne piège beaucoup de monde. Vérifier si un conteneur a fini d'être traité est une lecture, et cela exige quand même le scope de publication, parce que le conteneur est un artefact de la publication plutôt qu'une donnée de profil. Une app qui n'a demandé que basic ne peut rien créer, et ne peut rien voir non plus de ce qu'elle n'a pas réussi à créer.

La quatrième ligne compte pour la planification. Lire le quota est verrouillé derrière le même scope que le dépenser, donc une app ne peut pas vérifier la marge restante d'un compte avant de demander l'autorisation de publier. Cela vaut la peine d'être su quand vous développez contre les quotas de conteneurs et de publication que l'API applique par compte.

Notez ce qui manque à la liste. Rien de ce qui touche aux légendes, au texte alternatif, aux identifications d'utilisateurs ou aux lieux n'a sa propre permission. Ce sont des paramètres de POST /<IG_ID>/media, ce qui veut dire que la limite de 2 200 caractères de légende et ses sous-règles sur les tags sont appliquées par l'endpoint, pas par un scope que vous pourriez demander séparément.

Quel est son rapport avec les autres scopes Instagram ?

Il appartient à l'un de deux ensembles parallèles, et l'ensemble que vous utilisez est décidé par votre flux de connexion plutôt que par votre liste de fonctionnalités.

Business Login for Instagram	Facebook Login for Business
instagram_business_basic	instagram_basic
instagram_business_content_publish	instagram_content_publish
instagram_business_manage_comments	instagram_manage_comments
instagram_business_manage_messages	instagram_manage_messages
Fonctionnalité Human Agent	instagram_manage_insights
	pages_show_list, pages_read_engagement
	Human Agent, Instagram Public Content Access

L'infixe _business_ est le signe qui trahit. Ces scopes existent pour les apps où les utilisateurs se connectent avec leurs identifiants Instagram et tapent sur graph.instagram.com. Les noms plus courts existent pour les apps où les utilisateurs se connectent avec leurs identifiants Facebook, où le compte professionnel est lié à une Page Facebook, et où les appels partent vers graph.facebook.com.

La colonne Facebook Login traîne un bagage supplémentaire que la colonne Instagram n'a pas. Publier par ce flux exige aussi pages_read_engagement, et Meta ajoute une condition : si l'utilisateur de l'app a reçu son rôle sur la Page via le Business Manager, l'app a également besoin de ads_management ou de ads_read. Ce sont des scopes publicitaires exigés pour un post organique, uniquement à cause de la façon dont le rôle sur la Page a été attribué.

Il reste une asymétrie à lire avant de vous engager. Le tableau des tâches de Page de Meta relie ce qu'un utilisateur peut faire sur une Page à ce qu'il peut accorder à votre app, et Content (PROFILE_PLUS_CREATE_CONTENT) comme Full control (PROFILE_PLUS_FULL_CONTROL) accordent tous deux instagram_content_publish. Aucun tableau équivalent n'existe pour instagram_business_content_publish, parce que Business Login for Instagram n'a aucune Page au milieu. Sous Facebook Login, un utilisateur qui perd la tâche Content sur la Page fait perdre à votre app sa capacité de publier, sans que rien ne change dans votre app.

Les durées de vie des jetons sont partagées par les deux flux. Le code d'autorisation est valable une heure, le jeton d'accès de courte durée qu'il devient est valable une heure, et le jeton de longue durée que vous obtenez en échange est valable 60 jours et peut être renouvelé avant son expiration. Ce cycle de renouvellement est exactement celui qui se cache derrière le jeton Facebook de longue durée de 60 jours, et c'est la pièce de toute installation d'automatisation Instagram la plus susceptible de casser en silence.

Cycle de vie du token

1

Code d'autorisation. Valide une heure après la connexion.

2

Token d'accès de courte durée. Valide une heure.

3

Token d'accès de longue durée. Valide 60 jours, renouvelable avant son expiration.

Que demande l'App Review ?

Deux réponses écrites et une capture vidéo, et Meta publie la formulation exacte des trois.

L'intitulé de la description du cas d'usage : « Provide specific examples of why your app requires the instagram_business_content_publish permission to create and publish organic feed photo and video posts on behalf of other businesses. »

Les exigences de la capture vidéo, citées en entier :

Demonstrate the complete Instagram login process on your app platform, showing how your app user grants your app this permission

Demonstrate creating a new organic feed photo post on behalf of a business user

Show how to add a caption, hashtags, and other metadata, and post to the business user's Instagram feed

Lisez-les comme un plan de tournage. Le relecteur veut l'écran de consentement à l'image, un vrai post créé par votre interface, et les champs de légende et de hashtags remplis avant l'envoi. Un enregistrement qui commence après la connexion, ou qui montre un post déjà publié, rate deux exigences sur trois.

La revue ne devient nécessaire qu'à un seuil précis, que Meta rattache à la propriété plutôt qu'à l'échelle. Le Standard Access « is intended for apps that will only be used by people who have roles on them », et « If your app only serves your Instagram professional account or an account you manage, Standard Access is all your app needs. » L'Advanced Access est le niveau « required if your app serves Instagram professional accounts that you don't own or manage », et il « requires App Review and Business Verification. »

Donc un publieur interne à un seul compte n'a besoin d'aucune revue. Tout ce dans quoi un client se connecte exige la revue plus la vérification d'entreprise, et Meta ajoute un avertissement sur les tests entre les deux : « Because of the limited scope of Standard Access, some features might not work properly until your app has been granted Advanced Access. »

Il existe une porte de sortie, et la publication en est exclue. Pour les apps que les relecteurs ne peuvent pas tester, Meta écrit : « If reviewers are unable to test your app because it is behind a private intranet, has no user interface, or has not implemented Facebook Login for Business, you can request approval only for the following permissions: instagram_basic, instagram_manage_comments. » Aucun des deux scopes de publication n'apparaît sur cette liste. Un publieur headless sans interface n'a aucune voie documentée vers l'Advanced Access pour publier.

Pourquoi le scope dit-il feed alors que l'API publie des stories et des reels ?

Parce que Meta n'a jamais mis à jour le texte de la permission pour qu'il colle à l'endpoint. La description du scope dit « organic feed photo and video posts » depuis sa rédaction, alors que POST /<IG_ID>/media accepte les valeurs CAROUSEL, REELS et STORIES pour media_type, et que le tableau des prérequis de cette référence liste ce même scope pour toutes.

Rien dans la Permissions Reference ne mentionne les stories, les reels ou les carrousels. Rien dans la référence media ne réserve le scope aux posts de fil. Les deux documents décrivent la même permission à des largeurs différentes, et c'est l'endpoint qui est réellement appliqué.

La conséquence pratique relève de la revue, pas de l'exécution. Votre capture vidéo est notée par rapport aux mots de la référence des permissions, et ces mots demandent un post photo dans le fil. Montrer un reel ou une story à la place, c'est montrer quelque chose que la checklist du relecteur ne nomme pas. Enregistrez le post de fil que les exigences réclament, puis montrez le reste.

Un second décalage de formulation se trouve juste à côté. La ligne d'usage autorisé de Meta dit « post photos and videos », alors que la section Limitations du guide Content Publishing dit « Filters are not supported » et « Shopping tags are not supported. » Le scope accorde plus que ce que l'endpoint implémente.

Questions fréquentes

Qu'est-ce que instagram_business_content_publish ?

C'est la permission de l'Instagram Platform qui, selon les mots de Meta, « allows an app to create organic feed photo and video posts on behalf of a business user. » C'est le scope de Business Login for Instagram, utilisé avec l'hôte graph.instagram.com.

instagram_business_content_publish a-t-il besoin d'une autre permission à ses côtés ?

Oui. Meta liste instagram_business_basic comme sa dépendance, et le tableau des prérequis de chaque endpoint de publication nomme les deux scopes ensemble.

Quelle est la différence entre instagram_business_content_publish et instagram_content_publish ?

Le flux de connexion. Le premier est accordé par Business Login for Instagram, où les utilisateurs se connectent avec leurs identifiants Instagram. Le second est accordé par Facebook Login for Business et exige en plus instagram_basic et pages_read_engagement.

Publier des stories ou des reels exige-t-il une permission différente ?

Non. Le même scope couvre les valeurs REELS, STORIES et CAROUSEL de media_type, même si la description de la permission ne mentionne que les posts de fil.

Une app qui publie sur son propre compte Instagram a-t-elle besoin de l'App Review ?

Non. Meta indique que le Standard Access suffit si votre app « only serves your Instagram professional account or an account you manage. » L'Advanced Access, l'App Review et la Business Verification s'appliquent dès que l'app sert des comptes qui ne vous appartiennent pas.

Une app headless peut-elle faire approuver le scope de publication ?

Pas par l'exception des apps privées. Meta limite cette voie à instagram_basic et instagram_manage_comments, et aucun des deux scopes de publication n'apparaît sur la liste.

Une app peut-elle consulter son quota de publication avant d'avoir le scope ?

Ce n'est pas possible. L'endpoint GET /<IG_ID>/content_publishing_limit exige le même scope instagram_business_content_publish que les endpoints qui consomment ce quota, donc le quota restant reste invisible tant que la permission n'est pas déjà accordée.

Les légendes et les hashtags ont-ils besoin d'une permission distincte ?

Il n'existe pas de permission séparée pour ça. Les légendes, hashtags, texte alternatif, tags d'utilisateurs et localisations sont des paramètres de POST /<IG_ID>/media plutôt que des scopes à part, donc la limite de caractères de la légende et ses règles de tags sont appliquées par cet endpoint, pas par une permission demandée séparément.

Pourquoi Facebook Login for Business exige-t-il parfois une permission publicitaire juste pour publier ?

Publier via ce flux exige déjà pages_read_engagement en plus de instagram_content_publish et instagram_basic. Si le rôle de l'utilisateur de l'app sur la Page vient du Business Manager, Meta exige aussi ads_management ou ads_read, une condition liée à la façon dont le rôle a été attribué et non au contenu du post.

Que doit montrer le screencast de l'App Review pour ce scope ?

Trois choses : l'écran de connexion Instagram où l'utilisateur accorde la permission, un post photo dans le feed organique créé en direct depuis l'interface de l'app, et les champs de légende et de hashtags remplis avant la publication. Un enregistrement qui commence après la connexion ou qui montre un post déjà publié rate deux de ces trois exigences.