Publicaciones de Facebook que nadie veía: causa y solución en un flujo de n8n
Respuesta directa: si una automatización publica en una página de Facebook mediante la Graph API de Meta, recibe respuestas exitosas y el administrador ve las publicaciones, pero las personas ajenas a la página no las ven, revisa primero si la app de Meta que publica sigue en modo Desarrollo («Sin publicar»). En el caso que se documenta aquí, esa fue la causa. Una app sin publicar puede llamar a la API con normalidad, pero el contenido que crea queda restringido a quienes tienen un rol en la app o en la página. Al publicar la app, el problema se resolvió.
Fuente de este artículo: es un caso propio de Iezekiel Alvarado, documentado en un post-mortem interno sobre la página de Facebook de Acrox. Por seguridad, se omiten deliberadamente identificadores de la página, de la app y del flujo, así como tokens, credenciales y cualquier dato que pudiera usarse para acceder a esos sistemas. Lo que aquí se describe es lo observado en este caso; no es una declaración oficial de Meta.
¿Qué síntoma tenía la automatización?
Un flujo de n8n generaba y publicaba cada mañana una imagen con texto en una página de Facebook. Desde la cuenta del administrador todo se veía normal. Desde una cuenta ajena, el comportamiento se partía en dos:
En el timeline de la página, las publicaciones automáticas no aparecían.
En la pestaña Fotos, las imágenes sí estaban, con sus fechas correctas.
Las publicaciones hechas a mano desde Facebook sí aparecían en el timeline.
Esa asimetría fue la pista útil: el archivo existía y era público, pero la publicación asociada no se distribuía. Según el post-mortem, el problema afectó a unas 150 publicaciones durante más de cinco meses, desde abril hasta finales de septiembre de 2026.
¿Por qué no se detectó antes?
Porque ningún indicador estaba en rojo. n8n terminaba sin errores, Meta devolvía 200 OK y, al consultar el objeto por API, cada campo que normalmente explicaría una publicación oculta decía lo contrario:
El estado de publicación era «publicado» y el post no estaba oculto ni vencido.
La privacidad estaba en «público» y la visibilidad en el timeline era «normal».
No había segmentación de audiencia y la historia de feed existía.
La restricción no vivía en el objeto. Meta la aplica en la capa de distribución, según el estado de la app que publicó. Por eso ninguna consulta al post podía detectarla, y un 200 OK no significaba nada en este caso.
¿Cómo se midió algo que la API no muestra?
Si la API no puede ver el problema, hay que mirar desde fuera, como lo haría un visitante. Se usaron dos instrumentos, ambos sin sesión iniciada:
Una sonda anónima, que pide la publicación como lo haría el rastreador de Facebook y comprueba si Meta sirve sus metadatos públicos o responde que el contenido no está disponible.
Un navegador sin sesión, que abre la publicación y el timeline sin cuenta de Facebook y reproduce la experiencia de un visitante externo.
Una lección de instrumentación: las dos primeras mediciones fueron falsos negativos, una por leer un archivo obsoleto y otra por un límite de frecuencia de Facebook. Se detectaron porque cada medición incluía un control: una publicación manual conocida como visible. Cuando el control falla, hay que descartar la medición completa.
¿Qué evidencia señaló la causa?
Se midieron 39 publicaciones del periodo crítico y se cruzó su visibilidad pública contra quién las había creado. La correlación fue perfecta: las creadas por la app de automatización no estaban disponibles, y las hechas a mano sí.
El par más claro fue de un mismo día de abril: dos publicaciones con solo dos minutos de diferencia, en la misma página y con el mismo tipo de contenido. La única variable que cambiaba era quién publicaba. Eso descartó la fecha, el estado de la página, el tipo de post y el contenido.
También hubo una fecha de quiebre: la página publicó sin problema durante años, y la primera publicación invisible salió minutos después de emitir el token con el que empezó la automatización. Comparar la visibilidad a lo largo del tiempo ayuda a encontrar ese punto.
¿Qué hipótesis se descartaron?
Cada una se comprobó contra la API o con una prueba real:
El endpoint de fotos no crea historia de feed: falso, devuelve la historia y el post aparece en las publicaciones publicadas.
Usar el endpoint de feed con medios adjuntos lo arregla: falso, se implementó y el post quedó igual de invisible.
Parámetros que suprimen la historia o la publicación: no aplicaban, estaban ausentes en la llamada.
Token incorrecto o caducado: falso, el token era del tipo correcto y estaba vigente.
Permisos faltantes: falso, todos los necesarios estaban concedidos.
Restricciones de la página por edad o país: falso, no había ninguna.
Verificación de negocio pendiente: falso, se completó en junio y los posts siguieron ocultos.
¿Cuál era la causa real?
La app de Meta que publicaba estaba en modo Desarrollo. En el panel aparece como una etiqueta discreta en la barra lateral: «Publicar — Sin publicar». Una app sin publicar puede llamar a la API y recibir respuestas exitosas, pero todo el contenido que crea queda restringido a las personas con rol en la app o en la página.
Eso explica el patrón completo: el administrador lo veía, el visitante externo no, la imagen seguía siendo pública porque el álbum es de la página, y la API informaba «público» porque el objeto efectivamente lo es. Además, los permisos que usaba el flujo aparecían como «Listo para la prueba», una etiqueta que indica acceso estándar: el permiso funciona, pero solo surte efecto dentro del círculo de prueba.
Un efecto secundario que se descubrió en el proceso: la app estaba fijada en una versión obsoleta de la Graph API y Meta la reescribía en silencio a una versión más reciente en cada llamada. Solo se detecta añadiendo el parámetro de depuración a la petición.
¿Cómo se solucionó?
Publicando la app. No hizo falta un proceso de revisión con video, porque el negocio ya estaba verificado y el caso de uso era estándar. Lo que sí costó trabajo fue poder publicarla: la pantalla de requisitos exigía una URL de política de privacidad que parecía estar puesta, porque el formulario la mostraba llena, pero en el servidor estaba vacía.
Ese es un punto a vigilar: el formulario de Configuración básica del panel de Meta muestra lo que hay escrito en el navegador, no necesariamente lo que está guardado. Meta guarda la pantalla como un bloque, así que un solo campo inválido tumba el guardado completo y devuelve un error genérico que parece referirse a otra cosa. La forma de comprobarlo es leer la app por API y ver qué hay de verdad.
Los cambios al flujo fueron mínimos y reversibles, con respaldo previo:
Se actualizó la versión de la Graph API en los nodos que la usaban.
Se eliminó un parámetro que no estaba documentado.
Se migraron las credenciales que estaban escritas en los nodos a las credenciales cifradas de n8n.
El endpoint no se tocó: el que se usaba era el correcto desde el principio.
¿Cómo se verificó?
Se publicó un post de prueba con el método real de producción, se midió desde un navegador sin sesión y después se borró. El post nuevo apareció en el timeline público y renderizó desde su URL directa.
El resultado inesperado fue que la restricción se levantó de forma retroactiva: las publicaciones creadas mientras la app estaba sin publicar también se distribuyen ahora. Todo apunta a que la compuerta se evalúa al momento de la vista, según el estado actual de la app, y no queda grabada en el post. Esto es lo observado en este caso, no un comportamiento garantizado por Meta.
Una señal técnica confirmó el cambio: antes, la llamada de publicación de fotos devolvía solo el id de la foto, y después devolvió también el id del post.
Checklist para revisar una automatización que publica en Meta
Si una automatización publica en una página de Meta y el contenido no aparece para terceros, este orden ahorra tiempo:
Mira el modo de la app antes que nada. «Sin publicar» explica el síntoma completo.
No confíes en el 200 OK ni en los campos del post. Pueden decir «público» aunque nadie lo vea.
Mide desde fuera y con un control. Usa un navegador sin sesión e incluye siempre una publicación manual conocida como visible.
Busca la fecha de quiebre. Suele coincidir con un cambio de token o de app.
Correlaciona con el creador, no con el endpoint. El post indica qué app lo creó; cruza eso contra la visibilidad.
Verifica la configuración por API, no por pantalla. El panel puede mostrar valores sin guardar.
Añade el parámetro de depuración a una llamada. Revela versiones obsoletas que Meta corrige en silencio.
¿Qué riesgos quedan?
Versiones de la Graph API. Meta reescribe en silencio hasta que deja de hacerlo; conviene revisar la versión una vez al año.
Tokens. Un token de acceso de servidor puede dejar de funcionar si se rota su secreto, se le quitan activos o se elimina del negocio, y el flujo no avisa si eso pasa.
Sin verificación posterior a publicar. El flujo termina «correcto» aunque el post no se distribuya. Conviene añadir un paso que lea el id de historia devuelto y alerte si falta.
Correo de contacto vacío en la app. Ahí es donde Meta avisa de deprecaciones; sin él, el aviso de la versión obsoleta nunca llegó.
Qué no se sabe de este caso
No hay una declaración oficial de Meta que confirme el efecto retroactivo; se observó en las pruebas de este caso.
Las cifras (unas 150 publicaciones, 39 medidas) son las del post-mortem de la persona que operaba el flujo, sin auditoría independiente.
El caso corresponde a un tipo de acceso y a una configuración concretos; otras configuraciones de apps pueden comportarse distinto.
Preguntas frecuentes
¿Por qué mis publicaciones automáticas de Facebook devuelven 200 OK pero nadie las ve?
Una causa posible es que la app de Meta que publica esté en modo Desarrollo. En ese estado la API responde con éxito, pero el contenido solo es visible para quienes tienen un rol en la app o en la página.
¿Cómo compruebo si una publicación es realmente pública?
Ábrela en un navegador sin sesión de Facebook y revisa el timeline de la página, e incluye siempre una publicación manual conocida como control. Los campos del post pueden decir «público» aunque no se distribuya.
¿Cambiar de endpoint arregla el problema?
No en este caso. Se probó usar el endpoint de feed con medios adjuntos y el post siguió invisible; el endpoint de fotos que ya se usaba era correcto.
¿Las publicaciones antiguas siguen ocultas después de publicar la app?
En este caso dejaron de estar ocultas, porque la restricción parece evaluarse al momento de la vista según el estado actual de la app. No es un comportamiento que Meta garantice.
¿Es seguro compartir un post-mortem así?
Sí, siempre que se omitan identificadores de páginas, apps y flujos, tokens y credenciales. Lo que aporta valor es el método de diagnóstico, no los datos de acceso.
Si tienes una automatización que publica en redes y quieres revisar que de verdad llegue a tu audiencia, puedes contactar a Iezekiel Alvarado.
Comentarios