Publicar de inmediato mediante una API es sencillo. La programación es donde están los problemas interesantes, porque una publicación programada es una promesa sobre el futuro, y el futuro contiene el horario de verano, caídas de servicio y publicaciones sobre las que cambias de opinión.
Zonas horarias: pasa una de forma explícita
El error de programación más común es una publicación que se desplaza una hora dos veces al año.
Una hora programada necesita dos cosas: el instante, como una marca de tiempo ISO-8601, y la zona en la que se expresó, como un nombre IANA del tipo America/New_York.
await bp.posts.create({
content: 'Morning update.',
channels: [{ channelId: 1, platform: 'linkedin' }],
status: 'scheduled',
scheduledAt: '2026-04-10T14:00:00Z',
timezone: 'America/New_York',
});Guardar solo un instante en UTC funciona para algo puntual. Es incorrecto para cualquier cosa recurrente, porque “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. La zona es lo que lo hace correcto.
Nunca guardes un desfase horario en bruto como -05:00 como sustituto de una zona. Los desfases cambian; las zonas no.
Modela más de dos estados
Una publicación no es solo programada o publicada. Construye al menos para:
- draft, creada pero no en cola
- scheduled, en cola para una hora
- processing, enviada a la plataforma, resultado desconocido
- published, confirmada en directo
- failed, con un motivo
- partial, publicada en algunos destinos y no en otros
Los dos que la gente olvida son processing y partial.
processing 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 real llega después.
partial existe porque una publicación suele dirigirse a varias plataformas. Si tres tienen éxito y una falla, ni “published” ni “failed” son ciertos, y forzarlo a uno de los dos produce una interfaz que le miente al usuario.
Qué pasa cuando una plataforma está caída
Diséñalo, porque pasa.
Los fallos transitorios deberían reintentarse con espera progresiva. Una plataforma que devuelve 503 durante dos minutos no debería hacerte perder la publicación.
Los reintentos tienen que ser seguros. Una creación que agotó el tiempo de espera puede haber tenido éxito. Reintentar a ciegas duplica la publicación, que es peor que el fallo original. Comprueba antes de reintentar.
Los fallos permanentes no deberían reintentarse en absoluto. Un token caducado o una descripción no válida no se arreglan solos, y reintentar solo consume cuota y retrasa la notificación.
Alguien tiene que enterarse. Una publicación programada que falla a las 3 de la madrugada pasa desapercibida a menos que la hayas hecho ruidosa. Los webhooks son el mecanismo adecuado.
Editar y cancelar
Una publicación programada es una promesa que quizá tengas que romper. Tu integración debería admitir cambiar la hora, editar el contenido y cancelar por completo.
Ten en cuenta que las plataformas difieren en si permiten esto una vez que ellas tienen la publicación, lo que es una razón para programar en tu propia capa y enviar en el último momento, en lugar de entregarle a la plataforma una publicación con fecha futura.
Espacios de cola frente a horas explícitas
Dos modelos de programación, y ambos tienen su lugar.
Las horas explícitas son lo que quieres cuando una publicación tiene que llegar en un momento concreto: un lanzamiento, un evento, un anuncio coordinado.
Los espacios de cola son lo que quieres para un goteo constante. Defines una cadencia de publicación y la siguiente publicación toma el siguiente espacio libre, así que no eliges una marca de tiempo para cada publicación de un lote.
Para el trabajo en bloque, lo segundo es mucho menos tedioso, y es el modelo que hace que “poner en cola treinta publicaciones” sea una operación sensata en lugar de treinta decisiones.
Programaciones recurrentes
Distintas de una publicación programada. Una programación recurrente es una regla que sigue produciendo publicaciones con una frecuencia: diaria, semanal, quincenal o mensual.
Dos cosas para las que diseñar. La zona importa aún más aquí, por la razón del horario de verano de antes. Y los medios adjuntos a una publicación recurrente hay que conservarlos en lugar de limpiarlos tras publicar, porque la programación los necesita otra vez la próxima vez.
Límites de plan
| Free | Pro | Business | |
|---|---|---|---|
| Solicitudes de API/día | 30 | 5.000 | 50.000 |
| Publicaciones | 3/día | 30/día | Ilimitadas |
| Programaciones recurrentes | Ninguna | 10 | Ilimitadas |
La versión corta
Pasa una zona horaria IANA junto a cada marca de tiempo programada, especialmente para cualquier cosa recurrente. Modela processing y partial como estados reales, porque la publicación asíncrona y las publicaciones multiplataforma hacen que ambos ocurran de verdad. Reintenta los fallos transitorios con espera progresiva, nunca reintentes una creación a ciegas, y usa webhooks para que un fallo a las 3 de la madrugada no pase en silencio.