Tu producto necesita publicar en plataformas sociales. Alguien preguntará si integrar las plataformas directamente o usar una API de publicación, y la respuesta honesta depende de cosas que no aparecen en la primera estimación.
La estimación que siempre está mal
La primera estimación es para el camino feliz en una plataforma: consigue un token, publica algo de texto, listo. Esa parte es genuinamente un par de días.
Esto es lo que la estimación deja fuera, por plataforma.
Ciclo de vida del token. Los tokens caducan. Algunos en semanas. Renovarlos es una tarea programada, y cuando falla, el fallo es silencioso: la conexión está muerta, la publicación falla, y nadie se entera hasta que un usuario se queja. Necesitas detección y un flujo de reconexión.
Medios. Cada plataforma ingiere el material de forma distinta. Algunas obtienen una URL. Algunas quieren una subida por fragmentos reanudable. Algunas quieren dimensiones, duraciones o códecs específicos, y rechazan cualquier otra cosa. Vas a alojar y posiblemente transcodificar.
Publicación asíncrona. En varias plataformas, aceptar tu publicación no es publicarla. Obtienes un id y consultas el estado, y el eventual fallo llega mucho después de que tu solicitud devolviera 200. Tu modelo de datos necesita un estado de “creemos que esto se está publicando”, que no es obvio hasta que te topas con él.
Límites de frecuencia. Ventanas distintas, cabeceras distintas, comportamiento distinto al superarlos. Necesitas cola y espera progresiva por plataforma.
Aprobación. Varias plataformas condicionan la publicación a un proceso de revisión, con requisitos sobre tu aplicación, tu política de privacidad y a veces un vídeo de demostración. Esto es tiempo de calendario que no puedes comprimir, y puede denegarse.
Cambio continuo. Las versiones de la API se dan de baja según el calendario de la plataforma. Los campos cambian de nombre. Los permisos se endurecen. Cada uno es trabajo no planificado con una fecha límite que no fijaste tú.
Ese último punto es el que lo decide. Construir no es un proyecto que termina, es un compromiso de mantenimiento permanente que crece con cada plataforma.
La comparación real
No “unos pocos días por plataforma” frente a una suscripción. Es:
| Construir | Comprar | |
|---|---|---|
| Inicial | Semanas por plataforma, más tiempo de aprobación que no controlas | Una integración |
| Continuo | Cambios de plataforma, fallos de renovación de token, canalización de medios | Absorbido por el proveedor |
| Añadir una plataforma | Otra integración completa | Un parámetro |
| Modos de fallo | Tuyos, que detectar, depurar y explicar | Expuestos por el proveedor |
| Aprobación | Tuya de obtener y mantener por plataforma | Ya conseguida |
Cuándo construir es correcto
Tres casos donde de verdad lo es.
Una plataforma, de forma permanente. Si publicas en exactamente una red y eso no va a cambiar, una integración directa es más simple y elimina una dependencia.
Publicar es tu producto. Si tu diferenciador es la capa de publicación, eso es lo que deberías tener en propiedad.
Necesitas profundidad más allá de la publicación. Gestión de anuncios, moderación completa de comentarios, analíticas profundas. Estas van más allá de lo que cubre una API de publicación, y de todas formas acabarás en la propia API de la plataforma.
Cuándo comprar es correcto
Cualquier cosa que llegue a tres o más plataformas donde publicar sea una función y no el producto. El mantenimiento es el coste, no la construcción, y el mantenimiento escala con el número de plataformas mientras tu equipo no lo hace.
Además: cualquier cosa con una fecha límite. Los procesos de aprobación de plataforma tardan lo que tardan, y comprar significa que alguien ya pasó por ellos.
Qué comprobar antes de comprar
- La lista de plataformas admitidas, específicamente. No “todas las redes principales”
- Modelo de autenticación. Si tus usuarios conectan sus propias cuentas, necesitas OAuth, no solo una clave de API
- Límites de frecuencia en el nivel en el que realmente estarías
- Webhooks, para enterarte de los fallos sin consultar continuamente
- Si la validación ocurre antes de publicar. Detectar un pie de foto por encima del límite al momento de publicar significa una publicación fallida
- Qué pasa cuando una plataforma se rompe. Esto es lo que estás pagando
La API de BulkPublish
- URL base:
https://app.bulkpublish.com - Autenticación: clave de API para tu propia cuenta, OAuth 2.1 para actuar en nombre de las de otras personas
- Superficie: 59 endpoints documentados que cubren posts, programación, medios, canales, etiquetas, analíticas, feeds RSS y cuotas
- Plataformas: 15
| Free | Pro | Business | |
|---|---|---|---|
| Solicitudes de API/día | 30 | 5.000 | 50.000 |
| Claves de API | 1 | 5 | 10 |
| SDKs de Node y Python, una colección de Postman, y un servidor MCP para agentes de IA. El nivel gratuito está dimensionado para evaluar la API en lugar de para ejecutar tráfico de producción. |
La versión corta
La estimación de construir suele acertar sobre la primera plataforma y equivocarse sobre todo lo que viene después, porque el coste es el mantenimiento y no la construcción. Construye si estás en una plataforma para siempre, si publicar es tu producto, o si necesitas profundidad más allá de la publicación. En cualquier otro caso, la integración que no mantienes vale más que la que sí.