Si publicas de forma programática, se aplican dos límites de velocidad distintos y solo uno de ellos está bajo tu control.
Los dos niveles
El límite de la plataforma. Cada red social limita cuánto puede hacer cualquier aplicación en su API, con su propia ventana, sus propias cabeceras y su propio comportamiento al superarlo. Difieren de una plataforma a otra y cambian sin mucho aviso.
El límite de tu proveedor. Si publicas a través de una API unificada, ese servicio también tiene un límite, normalmente ligado a tu plan.
El segundo es fácil de leer y de planificar. El primero es el que muerde, porque nunca lo ves directamente si usas una API unificada. El proveedor lo absorbe, que es buena parte de lo que estás pagando, pero no desaparece: una plataforma que limita a todo el mundo sigue significando que tu publicación se retrasa.
Diseña para el retraso, no solo para los errores
El error más común en un pipeline de publicación es tratar “aceptado” como “publicado”.
En varias plataformas, enviar una publicación devuelve éxito y la publicación real ocurre después. Así que el fallo llega más tarde, fuera de banda, mucho después de que tu solicitud devolviera 200. Si tu modelo de datos solo tiene “enviado” y “fallido”, no hay dónde poner “creemos que esto se está publicando”.
Diseña para tres estados, y haz visible el pendiente.
Reglas prácticas
Espera de forma exponencial. Ante un 429, espera y reintenta con un retraso creciente. Los reintentos inmediatos empeoran la situación y pueden alargar el bloqueo.
Limita tus reintentos. Un pipeline que reintenta indefinidamente es como una cuota desaparece en minutos. Ríndete, registra el error de forma clara y deja que lo mire una persona.
Nunca reintentes una creación a ciegas. Si una solicitud de creación agota el tiempo de espera, no sabes si tuvo éxito. Reintentar puede producir publicaciones duplicadas, que es peor que el fallo original. Comprueba antes de reintentar, o usa un enfoque que haga seguro el reintento.
Agrupa cuando un endpoint lo admita. Una solicitud que crea muchas publicaciones cuesta una solicitud. El mismo trabajo en cincuenta llamadas individuales cuesta cincuenta.
Los límites propios de BulkPublish
| Free | Pro | Business | |
|---|---|---|---|
| Solicitudes de API/día | 30 | 5.000 | 50.000 |
| Claves de API | 1 | 5 | 10 |
| Publicaciones | 3/día | 30/día | Ilimitadas |
Las 30 solicitudes diarias del plan gratuito están pensadas deliberadamente para evaluar la API y ejecutar algo ligero y personal. No bastan para hacer funcionar un pipeline real, y un bucle sin espera progresiva lo agotará en segundos.
Ten en cuenta que las solicitudes de API y las publicaciones son límites separados. Listar canales, comprobar el estado y subir medios consumen solicitudes sin crear una publicación, así que el presupuesto de solicitudes rinde más de lo que sugiere el número de publicaciones solo si lo usas con cuidado.
Varias claves son para separar, no para más capacidad
Los planes de pago incluyen varias claves de API, y la razón no es más rendimiento. Es para que cosas distintas tengan credenciales distintas: tu pipeline de producción, un entorno de staging, un agente de IA.
El valor se nota cuando algo sale mal. Revocas una clave a las 2 de la madrugada en lugar de rotar la única credencial que comparte todo.
Una forma sensata de plantear un trabajo de publicación
- Busca los canales una vez al arrancar, no por publicación
- Sube los medios y luego crea las publicaciones referenciando los id
- Usa los endpoints de lote donde existan
- Gestiona el 429 con espera exponencial y un límite de reintentos
- Registra cada fallo con el cuerpo de la respuesta, porque nadie está mirando
La versión corta
Se aplican dos límites: el de la plataforma, que no ves a través de una API unificada, y el de tu proveedor, que sí. Espera de forma exponencial, limita los reintentos, nunca reintentes una creación a ciegas. Y trata “aceptado” como un estado distinto de “publicado”, porque en varias plataformas lo es de verdad.