Un agente que publica en redes sociales tiene requisitos distintos a los de una persona que lo hace, y la mayoría vienen del mismo hecho: nadie está mirando en el momento en que actúa.
Esta página es una lista de comprobación para valorar una API de publicación para uso con agentes, con los modos de fallo detrás de cada punto. Si buscas el recorrido práctico para conectar un agente y configurarlo con seguridad, consulta cómo dejar que un agente de IA publique en redes sociales. La página del producto sobre la API en sí es API de redes sociales para agentes de IA.
Lo que un agente necesita y una persona no
Un estado de borrador realmente útil. No una cola oculta, sino publicaciones que una persona pueda ver, revisar y publicar. Es la función más importante para la publicación con agentes y la que más a menudo se trata como una ocurrencia tardía.
Validación en el momento de crear la publicación. Una persona nota que una descripción es demasiado larga. Un agente no, y si la comprobación ocurre al publicar, el fallo llega horas después, cuando el agente ya no está. Los errores tienen que volver en la llamada de creación, donde el agente puede reaccionar.
Credenciales con alcance limitado y revocables. Separadas del resto de tus claves. Cuando algo sale mal quieres revocar exactamente al agente, no rotar la credencial que comparte tu flujo de producción.
Cuotas que frenan un bucle. Un bucle de reintentos puede producir muchas publicaciones muy rápido. Aquí un tope estricto es una medida de seguridad, no solo un nivel de facturación.
Errores estructurados. Un agente puede actuar ante “la descripción supera los 280 caracteres en x”. No puede actuar ante un 400 genérico.
Los modos de fallo contra los que diseñar
Invención con aplomo. Un modelo producirá una estadística, un precio o una afirmación de función verosímiles antes que decir que no lo sabe. No debe generarse nada factual. Los datos salen de una fuente que controle tu código.
Tormentas de reintentos. Un agente que trata un tiempo de espera agotado como un fallo y reintenta puede duplicar publicaciones, porque una creación que expiró puede haber tenido éxito. Los reintentos deben ser seguros o comprobados, nunca a ciegas.
Publicar en el momento equivocado. Un agente no sabe que hoy es un mal día para publicar algo alegre. Todo lo que roce las noticias o la polémica necesita a una persona.
Deriva de voz. Si se le deja solo, las publicaciones generadas convergen en el mismo registro, y la audiencia lo nota antes que tú.
Preguntas para hacer a cualquier API de publicación
| Pregunta | Cómo es una buena respuesta |
|---|---|
| ¿Se puede guardar una publicación sin publicarla? | Sí, como borrador, por el mismo endpoint |
| ¿Cuándo se comprueban los límites? | Al crear, con la plataforma nombrada en el error |
| ¿Se puede limitar una clave? | Por alcance, y revocarla por separado |
| ¿Qué pasa si se agota el tiempo de espera? | Puedes consultar la publicación antes de reintentar |
| ¿Qué frena un bucle? | Un tope diario de solicitudes y otro de publicaciones |
Lo que ofrece BulkPublish
- Conexión: un servidor MCP para asistentes, claves de API para tu propio código, OAuth 2.1 para actuar en cuentas de otras personas
- API: una API REST documentada que cubre publicaciones, programación, contenido multimedia, canales, etiquetas, analíticas, feeds RSS y cuotas
- Validación: límites de caracteres y reglas de contenido multimedia por plataforma comprobados al crear la publicación, no al publicar
- Plataformas: 15
| Free | Pro | Business | |
|---|---|---|---|
| Solicitudes de API/día | 10 | 5.000 | 50.000 |
| Claves de API | 1 | 5 | 10 |
| Publicaciones | 1/día | 30/día | Ilimitadas |
Los alcances de OAuth son granulares (posts:read, posts:write, media:read, media:write, analytics:read, channels:read, inbox:read, inbox:write y full), así que un agente que solo necesita crear publicaciones no recibe la bandeja de entrada.
La versión corta
Un agente necesita un estado de borrador real, validación al crear, credenciales con alcance limitado que pueda perder sin arrastrar nada más, y cuotas que frenen un bucle. Nunca le dejes generar un dato, y mantén a una persona entre la generación y la publicación hasta que tengas una razón de peso para no hacerlo.
