La parte de programación de un programador de redes sociales es cosa de un fin de semana. Una cola, un worker, un cron. Eso, de verdad, no es difícil, y por eso la estimación siempre está equivocada.
Todo lo caro está al otro lado de eso.
La parte fácil
Una tabla de publicaciones con una hora programada, un worker que se despierta, encuentra las publicaciones pendientes y las publica. Añade un reintento y ya está.
Si estás construyendo esto como proyecto de aprendizaje o para una sola plataforma que controlas, deja de leer aquí. El resto de esto trata sobre lo que ocurre cuando entran en juego cuentas reales y varias plataformas.
El modelo de datos que realmente necesitas
Más estados de los que la gente espera:
- borrador, creada pero no encolada
- programada, encolada para una hora
- en proceso, enviada a la plataforma, resultado desconocido
- publicada, confirmada
- fallida, con un motivo
- parcial, publicada en algunos destinos y en otros no
en proceso existe porque varias plataformas aceptan una publicación y la publican de forma asíncrona. Un 200 no es una publicación, y el resultado llega después, fuera de banda. Sin este estado, tu interfaz afirma un éxito que a veces es falso.
parcial existe porque una publicación suele dirigirse a varias plataformas. Tres tienen éxito, una falla. Ni “publicada” ni “fallida” son ciertas, y forzarlo a una de las dos produce un producto que miente a sus usuarios.
También necesitas filas por destino en lugar de un único estado en la publicación, porque el fallo es por plataforma.
Zonas horarias
Guarda el instante y la zona IANA, no un desfase.
“Cada día laborable a las 9 de la mañana hora local” es un instante UTC distinto antes y después de un cambio de horario de verano. Guardar solo UTC funciona hasta marzo, y entonces todo se desplaza una hora y los reportes de errores son confusos porque es correcto la mitad del año.
El trabajo por plataforma
Aquí es donde se rompe la estimación. Por plataforma:
Un flujo de OAuth independiente. Ámbitos distintos, vidas útiles de token distintas, pantallas de consentimiento distintas.
Un job de renovación independiente. Este es el que duele. Los tokens caducan, la renovación falla en silencio y nadie lo descubre hasta que una publicación programada no sale. Necesitas renovación programada, monitorización de fallos de renovación, un estado de conexión rota y un flujo de reconexión. Eso es más trabajo que el propio flujo de OAuth.
Un pipeline de contenido multimedia independiente. Una plataforma obtiene una URL, otra quiere una subida fragmentada reanudable, otra quiere dimensiones o códecs específicos. Vas a tener que alojar y posiblemente transcodificar.
Un límite de tasa independiente, con su propia ventana y su propio comportamiento al superarlo.
Revisión de la app. Varias plataformas restringen la publicación tras una revisión que incluye tu app, una política de privacidad y a veces un vídeo de demostración. Eso es tiempo de calendario que no controlas, y puede ser rechazado.
Cambio perpetuo. Las versiones de la API quedan obsoletas, los campos se renombran, los permisos se endurecen, según el calendario de las plataformas. Cada uno es trabajo no planificado con una fecha límite que tú no fijaste.
Multiplica por el número de plataformas. Y sigue pagándolo, para siempre.
Las reglas de publicación
Más allá de la entrega, lo que los usuarios realmente quieren es no publicar algo que será rechazado. Eso significa codificar por plataforma:
- Límites de caracteres
- Cantidades, tamaños, formatos, duraciones y proporciones de aspecto de los archivos multimedia
- Qué tipos de publicación requieren contenido multimedia
- Qué formatos existen siquiera
Y validar al crear en lugar de al publicar, porque un fallo en el momento de publicar es uno del que el usuario se entera cuando el momento ya pasó.
Constrúyelo si
- Publicas en exactamente una plataforma, de forma permanente
- Publicar es tu producto y tu diferenciador
- Necesitas ir mucho más allá de publicar, como la gestión de anuncios
No lo construyas si
Publicar es una función de otra cosa que estás construyendo y llega a tres o más plataformas. El coste no es la construcción, es el mantenimiento, y el mantenimiento escala con el número de plataformas mientras tu equipo no.
La alternativa
Una sola integración, donde la rotación de plataformas es problema de otro.
- URL base:
https://app.bulkpublish.com - Autenticación: clave de API, u OAuth 2.1 si actúas en nombre de las cuentas de tus usuarios
- Superficie: 59 endpoints documentados
- Plataformas: 15
- Validación: límites comprobados al crear, no al publicar
- SDKs: Node y Python, además de una colección de Postman y un servidor MCP
| Free | Pro | Business | |
|---|---|---|---|
| Solicitudes de API/día | 30 | 5.000 | 50.000 |
| Claves de API | 1 | 5 | 10 |
La versión corta
La cola es cosa de un fin de semana. Los estados, las zonas horarias y un flujo de OAuth más un job de renovación más un pipeline de contenido multimedia por plataforma son el proyecto real, y la rotación de plataformas hace que nunca termine. Constrúyelo si publicar es tu producto o si estás en una sola plataforma para siempre. Si no, la integración que no mantienes vale más que la que sí.