Publicar en Facebook e Instagram por API sin OAuth personal
Automatizar publicaciones en Facebook e Instagram suena a pocas llamadas a la Graph API de Meta: pedir un token, subir la imagen, publicar. En la práctica, al construir el panel de publicación Faro, aparecieron trampas que no están en el camino feliz de la documentación y que costaron horas de diagnóstico cada una.
Tu token personal no ve las páginas de la empresa
El camino que muestran casi todos los tutoriales es el diálogo OAuth: el usuario inicia sesión con Facebook, autoriza la app y se obtiene un token con el que se listan sus páginas. Con una página que pertenece a un portfolio comercial de Meta Business, esa lista vuelve vacía aunque la persona sea administradora directa de la página.
La solución correcta para un publicador automático, donde nadie confirma cada publicación, es un usuario del sistema. Se crea en la configuración del negocio, se le asignan como activos la página y la cuenta de Instagram con permiso de contenido, se le da un rol en la app de Meta, y recién entonces genera un token con los permisos necesarios. Conviene crear un usuario del sistema dedicado por integración, en vez de reutilizar uno de otro producto, para poder revocar uno sin romper los demás.
Como consecuencia, el panel no necesita ningún flujo OAuth: basta un formulario protegido donde se pega el token del usuario del sistema, que se guarda cifrado.
Instagram procesa hasta las imágenes en segundo plano
Publicar en Instagram es un proceso en dos pasos: primero se crea un contenedor con el archivo, y luego se publica ese contenedor. Con video es obvio que hay que esperar a que se procese. Lo que no es obvio es que con imágenes también. Publicar inmediatamente después de crear el contenedor falla con un error que dice que el medio no está disponible.
La regla es consultar siempre el estado del contenedor hasta que indique que terminó, sin importar el tipo de archivo, con un número máximo de intentos y una espera razonable entre cada uno.
Funciona en local y falla en el cron
El publicador corre por cron en el servidor. En desarrollo, las llamadas salientes se hacían con la función de PHP que lee una URL como si fuera un archivo, y funcionaban. En el servidor fallaban solo cuando las ejecutaba el cron. La causa: en ese hosting, la opción que permite abrir URLs estaba habilitada para el PHP que atiende la web, pero deshabilitada para el PHP de línea de comandos. La solución fue usar cURL para toda llamada saliente en código que corre fuera del servidor web.
Datos binarios en PostgreSQL desde PHP
Dos detalles del driver de PostgreSQL para PHP completaron la lista. Las columnas binarias llegan como un flujo de datos, no como texto, y hay que leerlas antes de usarlas. Al escribirlas, enviar el binario crudo como parámetro resultó poco fiable; lo estable fue convertirlo a hexadecimal y decodificarlo en la consulta SQL. Y los arreglos de texto de PostgreSQL llegan como el literal entre llaves, sin convertir, así que hay que parsearlos a mano.
Publicado significa confirmado
Con tantos pasos intermedios, la tentación es marcar una pieza como publicada cuando la llamada no dio error. El panel solo la marca cuando la red social devuelve el identificador de la publicación. Si algo falla, queda en estado de reintento y lo muestra. Un calendario que dice "publicado" sin serlo es peor que no tener calendario.
Resumen
- Para automatizar, usuario del sistema; no OAuth personal.
- Instagram: esperar el estado del contenedor siempre, también con imágenes.
- En cron, cURL para todas las llamadas salientes.
- El estado "publicado" solo con confirmación de la plataforma.