Qué concede realmente el scope instagram_business_content_publish

¿Qué concede instagram_business_content_publish?

Meta define el scope instagram_business_content_publish en una sola frase de 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 línea de uso permitido añade el límite: "Manage the organic content creation process for Instagram (for example, post photos and videos) on behalf of an Instagram business account."

Dos palabras de esa definición hacen casi todo el trabajo. Organic descarta cualquier cosa de pago, así que el scope no toca anuncios, publicaciones promocionadas ni promoción. On behalf of a business user significa que el permiso solo alcanza a las cuentas que se lo concedieron a tu app, y Meta expone ese límite de forma general en la visión general de la Instagram Platform: "a permission only allows access to data created by the app user who granted the permission."

El scope tampoco viaja nunca solo. Meta le asigna una dependencia, instagram_business_basic, y esa dependencia no es un formalismo. Basic aporta la identidad de la cuenta; publish aporta la escritura. Pedir publish sin basic deja a la app sin forma de resolver el ID de usuario de Instagram que todo endpoint de publicación necesita en su ruta.

¿Qué endpoints requieren el scope?

Cuatro, y Meta imprime la misma pareja de permisos en la tabla de requisitos de cada página de referencia.

Endpoint	Qué hace	Permisos para Instagram Login
POST /<IG_ID>/media	Crea el contenedor de medios	instagram_business_basic, instagram_business_content_publish
POST /<IG_ID>/media_publish	Publica el contenedor	instagram_business_basic, instagram_business_content_publish
GET /<IG_CONTAINER_ID>	Lee el estado del contenedor	instagram_business_basic, instagram_business_content_publish
GET /<IG_ID>/content_publishing_limit	Lee el consumo actual de la cuota	instagram_business_basic, instagram_business_content_publish

La tercera fila pilla a mucha gente. Comprobar si un contenedor terminó de procesarse es una lectura, y aun así necesita el scope de publicación, porque el contenedor es un artefacto de la publicación y no un dato de perfil. Una app que pidió basic a secas no puede crear nada y tampoco puede ver nada sobre lo que no consiguió crear.

La cuarta fila importa para la programación. Leer la cuota está protegido por el mismo scope que gastarla, así que una app no puede comprobar cuánto margen le queda a una cuenta antes de pedir permiso para publicar. Conviene tenerlo presente cuando construyes contra las cuotas de contenedores y publicaciones que la API aplica por cuenta.

Fíjate en lo que falta en la lista. Nada sobre pies de foto, texto alternativo, etiquetas de usuario o ubicaciones tiene permiso propio. Son parámetros de POST /<IG_ID>/media, lo que significa que el límite de 2.200 caracteres del pie de foto y sus subreglas de etiquetas los aplica el endpoint, no un scope que puedas pedir por separado.

¿Cómo se relaciona con los demás scopes de Instagram?

Pertenece a uno de dos conjuntos paralelos, y qué conjunto usas lo decide tu flujo de login, no tu lista de funciones.

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
Función Human Agent	instagram_manage_insights
	pages_show_list, pages_read_engagement
	Human Agent, Instagram Public Content Access

El infijo _business_ es la pista. Esos scopes existen para apps donde los usuarios inician sesión con credenciales de Instagram y llaman a graph.instagram.com. Los nombres más cortos existen para apps donde los usuarios inician sesión con credenciales de Facebook, la cuenta profesional está vinculada a una Facebook Page y las llamadas van a graph.facebook.com.

La columna de Facebook Login arrastra un lastre que la de Instagram no tiene. Publicar por ese flujo necesita además pages_read_engagement, y Meta añade una condición: si al usuario de la app le asignaron su rol en la Page a través del Business Manager, la app necesita también ads_management o ads_read. Son scopes de publicidad exigidos para un post orgánico, únicamente por cómo se asignó el rol en la Page.

Hay otra asimetría que conviene leer antes de comprometerse. La tabla de tareas de Page de Meta relaciona lo que un usuario puede hacer en una Page con lo que puede concederle a tu app, y tanto Content (PROFILE_PLUS_CREATE_CONTENT) como Full control (PROFILE_PLUS_FULL_CONTROL) conceden instagram_content_publish. No existe tabla equivalente para instagram_business_content_publish, porque el Business Login for Instagram no tiene ninguna Page de por medio. Con Facebook Login, un usuario que pierde la tarea Content en la Page hace que tu app pierda la capacidad de publicar, sin que nada cambie en tu app.

Las duraciones de los tokens son comunes a ambos flujos. El código de autorización vale una hora, el token de acceso de corta duración en el que se convierte vale una hora, y el token de larga duración por el que lo canjeas vale 60 días y se puede renovar antes de que caduque. Ese ciclo de renovación es el mismo que hay detrás del token de larga duración de Facebook de 60 días, y es la pieza de cualquier montaje de automatización de Instagram que más probablemente se rompa en silencio.

Ciclo de vida del token

1

Código de autorización. Válido durante una hora tras el login.

2

Token de acceso de corta duración. Válido durante una hora.

3

Token de acceso de larga duración. Válido durante 60 días, renovable antes de que caduque.

¿Qué pide el App Review?

Dos respuestas escritas y un screencast, y Meta publica la redacción exacta de las tres.

El enunciado de la descripción del caso de uso: "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."

Los requisitos del screencast, citados enteros:

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

Léelos como un guion de rodaje. El revisor quiere la pantalla de consentimiento grabada, un post real creado desde tu interfaz, y los campos de pie de foto y hashtags rellenados antes de que salga. Una grabación que arranca después del login, o que enseña un post ya publicado, incumple dos de los tres requisitos.

La revisión solo se vuelve necesaria a partir de un umbral concreto, que Meta ata a la propiedad y no a la escala. El Standard Access "is intended for apps that will only be used by people who have roles on them", y "If your app only serves your Instagram professional account or an account you manage, Standard Access is all your app needs." El Advanced Access es el nivel "required if your app serves Instagram professional accounts that you don't own or manage", y "requires App Review and Business Verification."

Así que un publicador interno de una sola cuenta no necesita revisión. Todo aquello en lo que inicie sesión un cliente necesita revisión más verificación de empresa, y Meta añade una advertencia sobre las pruebas intermedias: "Because of the limited scope of Standard Access, some features might not work properly until your app has been granted Advanced Access."

Existe una salida de emergencia, y la publicación queda fuera de ella. Para las apps que los revisores no pueden probar, Meta escribe: "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." Ninguno de los dos scopes de publicación aparece en esa lista. Un publicador headless sin interfaz no tiene ninguna vía documentada hacia el Advanced Access para publicar.

¿Por qué el scope dice feed si la API publica stories y reels?

Porque Meta nunca actualizó el texto del permiso para que coincidiera con el endpoint. La descripción del scope dice "organic feed photo and video posts" desde que se escribió, mientras que POST /<IG_ID>/media acepta valores de media_type de CAROUSEL, REELS y STORIES, y la tabla de requisitos de esa referencia lista este mismo scope para todos ellos.

Nada en la Permissions Reference menciona stories, reels ni carruseles. Nada en la referencia de media restringe el scope a posts de feed. Los dos documentos describen el mismo permiso con anchuras distintas, y el endpoint es el que de verdad se aplica.

La consecuencia práctica es de revisión, no de ejecución. Tu screencast se califica frente a las palabras de la referencia de permisos, y esas palabras piden un post de foto en el feed. Demostrar un reel o una story es demostrar algo que la lista del revisor no nombra. Graba el post de feed que piden los requisitos y luego enseña el resto.

Justo al lado hay un segundo desajuste de redacción. La línea de uso permitido de Meta dice "post photos and videos", mientras que la sección de Limitations de la guía de publicación de contenido dice "Filters are not supported" y "Shopping tags are not supported." El scope concede más de lo que implementa el endpoint.

Preguntas frecuentes

¿Qué es instagram_business_content_publish?

Es el permiso de la Instagram Platform que, en palabras de Meta, "allows an app to create organic feed photo and video posts on behalf of a business user." Es el scope de Business Login for Instagram, que se usa con el host graph.instagram.com.

¿instagram_business_content_publish necesita otro permiso a su lado?

Sí. Meta lista instagram_business_basic como su dependencia, y la tabla de requisitos de cada endpoint de publicación nombra los dos scopes juntos.

¿Cuál es la diferencia entre instagram_business_content_publish e instagram_content_publish?

El flujo de login. El primero se concede a través del Business Login for Instagram, donde los usuarios inician sesión con credenciales de Instagram. El segundo se concede a través del Facebook Login for Business y requiere además instagram_basic y pages_read_engagement.

¿Publicar stories o reels necesita un permiso distinto?

No. El mismo scope cubre los valores de media_type REELS, STORIES y CAROUSEL, aunque la descripción del permiso solo mencione posts de feed.

¿Una app que publica en su propia cuenta de Instagram necesita App Review?

No. Meta afirma que el Standard Access basta si tu app "only serves your Instagram professional account or an account you manage." El Advanced Access, el App Review y la Business Verification se aplican en cuanto la app sirve a cuentas que no son tuyas.

¿Puede una app headless conseguir la aprobación del scope de publicación?

No por la excepción de app privada. Meta limita esa vía a instagram_basic e instagram_manage_comments, y ninguno de los dos scopes de publicación aparece en la lista.

¿Puede una app consultar su cuota de publicación antes de tener el scope?

Consultarla antes no es posible. El endpoint GET /<IG_ID>/content_publishing_limit exige el mismo scope instagram_business_content_publish que los endpoints que gastan la cuota, así que la cuota restante queda oculta hasta que el permiso ya está concedido.

¿Los captions y hashtags necesitan un permiso propio?

Eso no exige un permiso propio. Los captions, hashtags, alt text, etiquetas de usuario y ubicaciones son parámetros de POST /<IG_ID>/media en lugar de scopes independientes, así que el límite de caracteres del caption y sus reglas de etiquetado los aplica ese endpoint, no un permiso que se pida por separado.

¿Por qué Facebook Login for Business a veces exige un permiso de publicidad solo para publicar?

Publicar por ese flujo ya exige pages_read_engagement junto a instagram_content_publish e instagram_basic. Si el rol del usuario de la app en la Page se asignó desde Business Manager, Meta exige también ads_management o ads_read, una condición ligada a cómo se asignó el rol y no al contenido de la publicación.

¿Qué tiene que mostrar el screencast del App Review para este scope?

Tres cosas: la pantalla de login de Instagram donde el usuario concede el permiso, un post de foto en el feed orgánico creado en vivo desde la interfaz de la app, y los campos de caption y hashtags rellenados antes de publicar. Una grabación que empieza después del login o que muestra un post ya publicado deja sin cumplir dos de esos tres requisitos.