Publicar en Threads requiere dos llamadas a la API, no una: creas un contenedor de medios y luego lo publicas. Los perfiles están limitados a 250 publicaciones vía API cada 24 horas, las publicaciones de texto tienen un tope de 500 caracteres, y cada permiso que use tu aplicación debe pasar la Revisión de Aplicaciones de Meta antes de que nadie fuera de tu lista de testers pueda conectarse.
¿Qué puede publicar la API de Threads y qué no?
Las publicaciones individuales admiten tres tipos de medios: TEXT, IMAGE y VIDEO. Los carruseles admiten elementos hijos de tipo IMAGE y VIDEO, entre 2 y 20, y un carrusel cuenta como una sola publicación contra tu límite de publicación.
Las especificaciones, según la propia documentación de Meta:
| Restricción | Valor |
|---|---|
| Longitud del texto | 500 caracteres |
| Elementos del carrusel | 2 a 20 |
| Formatos de imagen | JPEG, PNG |
| Tamaño de archivo de imagen | 8 MB máximo |
| Ancho de imagen | 320 a 1440 píxeles |
| Relación de aspecto de imagen | 10:1 máximo |
| Contenedor de video | MOV o MP4 |
| Códecs de video | video H264 o HEVC, audio AAC |
| Frecuencia de fotogramas de video | 23 a 60 FPS |
| Duración del video | 300 segundos (5 minutos) |
| Tamaño de archivo de video | 1 GB máximo |
| Bitrate de video | 100 Mbps video, 128 kbps audio |
Un detalle que sorprende a la gente: los emojis cuentan contra los 500 caracteres por su valor de byte UTF-8, no como caracteres individuales. Una descripción que parece tener 480 caracteres en tu editor puede ser rechazada. Si estás contando en el cliente, cuenta bytes para los emojis. La publicación sobre el límite de caracteres de Threads y el contador de caracteres de Threads gratis manejan esto correctamente.
Nota: Estas cifras se verificaron con developers.facebook.com/docs/threads/posts y /docs/threads/overview a fecha de septiembre de 2026. Las plataformas cambian estos datos sin previo aviso.
¿Cómo funciona el modelo de autenticación?
Threads corre sobre la infraestructura de aplicaciones de Meta pero con sus propias credenciales. Creas una aplicación de Meta con el caso de uso de Threads, y esa aplicación emite un ID y un secreto de aplicación específicos de Threads, distintos de los que se muestran en otras partes del panel. Usar el par equivocado es un error común de la primera hora.
Los alcances (scopes) son granulares:
threads_basic(obligatorio para cada endpoint)threads_content_publish(publicación)threads_manage_repliesythreads_read_repliesthreads_manage_insightsthreads_deletethreads_location_tagging
La revisión de la aplicación no es opcional. Cada permiso debe aprobarse mediante la Revisión de Aplicaciones, y la aplicación debe estar publicada en producción, antes de que cualquier usuario que no sea tester pueda concederlo. Hasta entonces, solo puedes publicar en perfiles de Threads que hayas invitado explícitamente como testers desde el panel de la aplicación, y que hayan aceptado la invitación desde su configuración de Threads. La documentación de Meta no indica cuánto tarda la revisión, así que no vamos a especular.
El ciclo de vida del token que tienes que construir
Esta es la parte que se convierte en una tarea programada.
- La ventana de autorización devuelve un código.
- Cámbialo por un token de acceso de corta duración, válido durante 1 hora.
- Cambia ese por un token de larga duración mediante
GET /access_tokencongrant_type=th_exchange_token. Válido durante 60 días. - Renuévalo mediante
GET /refresh_access_tokencongrant_type=th_refresh_token. Un token debe tener al menos 24 horas de antigüedad y no haber caducado para poder renovarse. Un token renovado es válido durante otros 60 días.
Un token que pasa 60 días sin renovarse caduca y el usuario debe volver a autorizar. Los permisos concedidos por usuarios de la aplicación con perfiles privados son válidos durante 90 días.
Nota: Estas cifras se verificaron con developers.facebook.com/docs/threads/get-started y /get-started/long-lived-tokens a fecha de septiembre de 2026. Las plataformas cambian estos datos sin previo aviso.
¿Cuál es la secuencia real de publicación?
Para una publicación individual:
POST /{threads-user-id}/threadsconmedia_typey tu texto o URL de medios. Esto devuelve un ID de contenedor.- Espera. Meta recomienda una media de 30 segundos antes de publicar, para dejar que el servidor termine de procesar el medio.
POST /{threads-user-id}/threads_publishcon ese ID de contenedor.
Para un carrusel, añade un paso: crea un contenedor por cada elemento hijo, luego crea un contenedor de carrusel que los referencie, y por último publícalo.
# 1. create the container
curl -X POST "https://graph.threads.net/v1.0/$USER_ID/threads" \
-d "media_type=IMAGE" \
-d "image_url=https://example.com/photo.jpg" \
-d "text=Shipping notes for this week." \
-d "access_token=$TOKEN"
# -> {"id":"1789..."}
# 2. wait ~30s for processing, then publish
curl -X POST "https://graph.threads.net/v1.0/$USER_ID/threads_publish" \
-d "creation_id=1789..." \
-d "access_token=$TOKEN"Ten en cuenta que las imágenes y los videos se pasan mediante URL pública, no se suben como bytes. Los servidores de Meta los recuperan. Eso significa que tus medios tienen que ser accesibles públicamente, sin autenticación, y seguir disponibles cuando se produzca la recuperación, un requisito de alojamiento que la mayoría de la gente no prevé.
¿Cuáles son los límites de velocidad?
| Acción | Límite |
|---|---|
| Publicaciones publicadas | 250 por período móvil de 24 horas |
| Respuestas | 1.000 cada 24 horas |
| Eliminaciones | 100 cada 24 horas |
| Búsquedas de ubicación | 500 cada 24 horas |
| Llamadas generales a la API | 4800 x número de impresiones, cada 24 horas (mínimo 10 impresiones) |
Vale la pena leer dos veces la fórmula de las impresiones. Tu presupuesto de llamadas generales escala con el alcance real que consigue el perfil, con un mínimo garantizado. Un perfil recién creado tiene el presupuesto mínimo.
Nota: Estas cifras se verificaron con developers.facebook.com/docs/threads/overview a fecha de septiembre de 2026. Las plataformas cambian estos datos sin previo aviso.
¿Qué te va a costar realmente tres semanas?
La Revisión de la Aplicación. Preparar capturas de pantalla en video, una política de privacidad, un flujo de demostración funcional y una verificación empresarial, y luego iterar sobre los rechazos. La duración no está publicada, así que planifícala como un riesgo de calendario y no como una tarea.
La tarea de renovación del token. Los tokens de larga duración caducan en 60 días y solo se pueden renovar una vez que tienen 24 horas de antigüedad. Eso implica una tarea programada, un almacén de tokens cifrados, una vía de alerta cuando falla la renovación y un flujo de reconexión en tu interfaz.
Fallo asíncrono. Que la llamada de contenedor devuelva 200 no significa que tu medio sea válido. La llamada de publicación es donde aparece un video defectuoso, unos 30 segundos después, en una petición distinta. Tu modelo de publicación necesita un estado de processing y una forma de reportar un fallo que llegó después de que el usuario cerrara la pestaña.
Alojamiento público de medios. Como Meta recupera por URL, necesitas URLs públicas duraderas con un comportamiento de caché sensato, y un plan para lo que pasa cuando la recuperación es limitada o bloqueada por la protección antibots de tu CDN.
Contar bytes para los emojis. Barato de arreglar, caro de descubrir en producción.
En resumen
- Dos llamadas para publicar: crear un contenedor, esperar unos 30 segundos, publicarlo. Tres para un carrusel.
- Los medios se pasan por URL pública. Meta los recupera.
- 500 caracteres. Los emojis cuentan como bytes UTF-8.
- 250 publicaciones vía API por perfil cada 24 horas.
- Los tokens de corta duración duran 1 hora, los de larga duración 60 días, renovables una vez tienen 24 horas.
- La Revisión de la Aplicación es obligatoria por permiso antes de que se conecten usuarios que no son testers. No hay una duración publicada.
Programar Threads junto con todo lo demás
Si Threads es una plataforma más dentro de un conjunto en vez de todo el producto, la mayor parte del trabajo anterior se repite por cada red con formas distintas. X usa OAuth 2.0 PKCE y subidas por bytes fragmentadas. Bluesky no necesita ninguna revisión de aplicación. LinkedIn necesita dos aplicaciones separadas: los perfiles personales usan w_member_social, las páginas de empresa usan r_organization_social, w_organization_social y rw_organization_admin, revisadas por separado.
BulkPublish cubre 15 plataformas a través de una sola API REST, incluyendo Threads, con la secuencia de contenedor, la renovación de 60 días y el sondeo de estado asíncrono gestionados en el servidor. La documentación para desarrolladores y la referencia de la API REST enumeran los endpoints, y cómo programar publicaciones en Threads cubre la vía para quien no es desarrollador.