Tus usuarios crean algo en tu producto y luego se van a publicarlo en otro sitio. Cerrar esa brecha es una solicitud de función habitual, y la forma del trabajo depende casi por completo de una decisión que se toma al principio.
La decisión: ¿de quién es la cuenta?
Si las publicaciones van a tus propias cuentas, una clave de API basta. De servidor a servidor, sin flujo de consentimiento, lo más sencillo posible.
Si las publicaciones van a las cuentas de tus usuarios, necesitas OAuth. Cada usuario autoriza tu app y recibes un token con alcance limitado vinculado al espacio de trabajo que eligió.
Acierta con esto desde el principio. Los productos que empiezan pidiendo a los usuarios que peguen una clave de API acaban migrando a OAuth más tarde, y mientras tanto han enseñado a los usuarios un hábito malo para ambas partes: pegar una credencial de larga duración y amplio acceso en un producto de terceros.
Lo que tendrías que construir si no
La razón para usar una API de publicación en lugar de integrar las plataformas directamente es que la integración directa es un proyecto por plataforma que nunca termina:
- Un flujo de OAuth distinto por plataforma, con alcances y duraciones de token diferentes
- Un trabajo de renovación por plataforma, que falla en silencio y se lleva la publicación con él
- Un pipeline de medios distinto por plataforma, con modelos de subida diferentes
- Publicación asíncrona en varias, donde un 200 no significa publicado
- Un límite de velocidad distinto por plataforma
- Revisión de la app en varias, que es tiempo de calendario que no controlas y que puede ser rechazado
- Cambios que rompen cosas de forma continua, según el calendario propio de cada plataforma
Para un SaaS en el que publicar es una función y no el producto, eso es un compromiso de mantenimiento permanente sobre algo que no es tu diferenciador.
Lo que sigues teniendo que construir
Usar una API de publicación no elimina todo el trabajo. Aún necesitas:
Una interfaz de conexión. Un lugar donde los usuarios conecten sus cuentas y vean el estado de la conexión.
Un estado de rotura visible. Las conexiones se rompen. Los usuarios necesitan verlo y arreglarlo, y tiene que ser un estado dentro de tu producto, no un error que te tragas.
Composición, en los términos de tu producto. La API toma contenido y canales. Lo que tus usuarios hacen realmente, y cómo se convierte eso en una publicación, es cosa tuya.
Manejo de fallos. Algo fallará al publicar. Decide ahora si el usuario se entera por ti o por la ausencia de una publicación.
Qué comprobar al elegir
| Requisito | Por qué |
|---|---|
| OAuth con alcances granulares | Los productos multiusuario lo necesitan, y los alcances estrechos limitan el radio de impacto |
| La lista concreta de plataformas | No “todas las redes principales” |
| Validación al crear | Para que una descripción que supera el límite falle donde puedas mostrárselo al usuario |
| Límites de velocidad en tu nivel | El número que decide si escala contigo |
| Errores estructurados | Para poder mostrar algo útil en lugar de “fallo al publicar” |
BulkPublish para esto
- Autenticación: OAuth 2.1 para actuar sobre las cuentas de tus usuarios, claves de API para las tuyas
- Detalles de OAuth: PKCE (S256) obligatorio,
scopeobligatorio sin valor por defecto implícito, códigos de autorización de un solo uso, tokens de renovación rotatorios, tokens pasados comoBearer bpat_... - Alcances:
posts:read,posts:write,media:read,media:write,analytics:read,channels:read,full - Superficie: 59 endpoints documentados
- Plataformas: 15
Un límite en torno al cual diseñar: los tokens de OAuth llegan a publicaciones, programaciones, etiquetas, medios, analítica, uso de cuota y datos de canal de solo lectura. La administración de la cuenta, es decir, equipo, organizaciones, facturación, compras de créditos, claves de API y gestión de apps OAuth, devuelve 403 para cualquier token OAuth, incluido full, porque esas acciones sobrevivirían a que un usuario desconecte tu app. Eso necesita una clave de API.
Mejor saberlo ahora que encontrarlo como un 403 sin explicación en producción.
| Free | Pro | Business | |
|---|---|---|---|
| Solicitudes de API/día | 30 | 5.000 | 50.000 |
| Claves de API | 1 | 5 | 10 |
La versión corta
Decide primero si vas a publicar en tus propias cuentas o en las de tus usuarios. Si son las de los usuarios, usa OAuth desde el primer día en lugar de migrar más tarde. Integrar las plataformas directamente es un compromiso de mantenimiento permanente sobre algo que no es tu producto, y las partes que aún tienes que construir son la interfaz de conexión, un estado de rotura visible y avisar a los usuarios cuando algo falle.