Cómo funciona el límite de 250 posts por día de la API de Threads

¿Qué es el límite de 250 posts por día de la API de Threads?

Meta aplica el límite de 250 posts por día de la API de Threads al paso de publicación, así que un perfil de Threads puede convertir 250 contenedores de medios en posts en vivo en cualquier periodo móvil de 24 horas. La frase está en la sección Rate Limiting de la página general de Threads de Meta y dice: "Threads profiles are limited to 250 API-published posts within a 24-hour moving period. Carousels count as a single post. This limit is enforced on the POST /{threads-user-id}/threads_publish endpoint when attempting to publish a media container."

Tres detalles de ese pasaje deciden cómo se comporta una cola. "API-published" acota el recuento a los posts enviados a través de la API de Threads y no a los escritos en la app de Threads. "Moving" descarta un reinicio a medianoche. Y nombrar threads_publish como punto de aplicación significa que crear contenedores sale gratis, porque el contador solo se mueve cuando un contenedor se convierte en post.

Meta añade una cuarta frase dirigida de lleno a quien construya un programador: "We recommend that your app also enforces the publishing rate limit, especially if your app allows app users to schedule posts to be published in the future."

¿Cómo funciona la ventana de 24 horas?

La ventana se desplaza, y cada publicación sale del recuento 24 horas después de ocurrir, no a una hora fija. Un perfil que quema los 250 espacios entre las 08:00 y las 09:00 del lunes recupera esa capacidad entre las 08:00 y las 09:00 del martes, publicación a publicación, no de golpe a medianoche.

El endpoint de cuota pone un número a la ventana. Su objeto config lleva quota_duration: 86400, que son 24 horas en segundos, junto a quota_total: 250. Nada en la documentación de Threads expone las marcas de tiempo de las publicaciones individuales, así que la única forma de saber cuánto margen queda en este segundo es preguntárselo a Meta.

¿Qué endpoint informa de la cuota restante?

GET /{threads-user-id}/threads_publishing_limit devuelve el recuento propio del perfil, y Meta lo describe como la forma "To validate that a user has not exhausted their API quota limits for publishing, reply publishing, deleting, and location search." Dos campos cubren la publicación: quota_usage, que Meta define como "Threads publishing count over the last 24 hours", y config, que contiene quota_total y quota_duration.

curl -s -X GET \
"https://graph.threads.net/v1.0/<THREADS_USER_ID>/threads_publishing_limit?fields=quota_usage,config&access_token=<ACCESS_TOKEN>"

{
  "data": [
    {
      "quota_usage": 4,
      "config": {
        "quota_total": 250,
        "quota_duration": 86400
      }
    }
  ]
}

La llamada necesita los permisos threads_basic y threads_content_publish. Leer quota_total en lugar de escribir 250 a fuego es la diferencia entre una integración que sobrevive a un cambio de cuota y otra que se limita a sí misma en silencio durante un año después de que Meta suba el techo.

¿Cuáles son las demás cuotas de la API de Threads?

El mismo endpoint informa de cuatro presupuestos distintos, cada uno con su pareja de campos y su propio techo. Todos usan un quota_duration de 86400 segundos.

Las respuestas tienen su propio presupuesto de 1.000, que Meta expresa como "Threads profiles are limited to 1,000 replies within a 24-hour moving period." Un bot que contesta comentarios tiene por tanto cuatro veces el margen de uno que publica, y gastar cuota de respuestas nunca toca los 250. Ninguno de estos presupuestos interactúa con el techo de 500 caracteres del texto del post, que se aplica al crear el contenedor y no al publicar, y que está cubierto en el límite de caracteres de Threads.

¿Un carrusel cuenta como un post o como veinte?

Un carrusel cuenta como una publicación, lleve lo que lleve. Meta lo escribe dos veces: "Carousels count as a single post" en la página general, y "Publishing a carousel counts as a single post" en el recorrido de carruseles. Como un carrusel de Threads admite hasta 20 hijos, un perfil que solo publica carruseles completos mueve 5.000 imágenes y videos individuales en 250 publicaciones.

Esa proporción es la única palanca real que existe sobre este tope. Diez imágenes sueltas cuestan diez de los 250 espacios. Esas mismas diez enviadas como un carrusel cuestan uno. Quien esté cerca del techo debería agrupar medios antes de pedir más margen, que es la misma aritmética que hay detrás del tope de 100 posts por 24 horas de la API de Instagram.

¿Por qué las dos páginas de Meta redactan el mismo límite de forma distinta?

El número coincide entre páginas y la redacción no. La página general dice "250 API-published posts within a 24-hour moving period". El recorrido de carruseles, en una nota sobre el paso 3, dice "Profiles are limited to 250 published posts within a 24-hour period."

La segunda versión se deja "API-" y se deja "moving". Leída al pie de la letra, cubriría los posts hechos a mano en la app y se reiniciaría con un reloj fijo. Meta nunca concilia las dos, y solo la página general lleva el detalle de aplicación que nombra threads_publish, así que la página general es la formulación más completa de la misma regla. Toma la frase corta como una abreviatura y no como una segunda política.

¿Qué error devuelve Threads cuando se agota la cuota?

Meta no documenta ningún código de error por superar la cuota de publicación. El índice de la referencia de la API de Threads lista nueve páginas de endpoints y ninguna página de códigos de error, y la página de troubleshooting solo cubre resultados de contenedores: los valores de status EXPIRED, ERROR, FINISHED, IN_PROGRESS y PUBLISHED, más valores de error_message de video como FAILED_DOWNLOADING_VIDEO e INVALID_ASPEC_RATIO.

La única cadena de fallo en el momento de publicar que Meta sí documenta no tiene que ver con el volumen. Desde el 22 de diciembre de 2025, un post con más de cinco enlaces falla en el paso del contenedor con THREADS_API__LINK_LIMIT_EXCEEDED. No hay una constante equivalente para los 250.

Esa ausencia es la razón por la que Meta pide a las apps que apliquen el límite por su cuenta. El código escrito contra una respuesta de fallo no documentada es una conjetura; el código que lee quota_usage antes de publicar está consultando el mismo contador que consulta Meta.

¿En qué se diferencia el límite de tasa por app de los 250?

Los 250 son un presupuesto de publicación a nivel de perfil. Aparte, cada llamada a la API de Threads cuenta contra la app que la hace, y Meta le da una fórmula en lugar de una constante: Calls within 24 hours = 4800 * Number of Impressions, donde las impresiones son "the number of times any content from the app user's Threads account has entered a person's screen within the last 24 hours". El valor mínimo de impresiones es 10, así que el suelo son 48.000 llamadas por pareja de app y usuario.

Con él viajan dos presupuestos de CPU, 720000 * number_of_impressions para el tiempo total de CPU y 2880000 * Number of Impressions para el tiempo total. La misma forma basada en impresiones rige el límite de tasa de 4800 impresiones de la API de Instagram, lo que no sorprende dado que las dos corren sobre infraestructura de Meta.

Un perfil puede por tanto llegar a 250 publicaciones sin acercarse a su presupuesto de llamadas, ya que consultar el estado de un contenedor, leer insights y traer respuestas gastan llamadas sin gastar publicaciones.

¿Qué significa el tope para una cola de programación?

Los 250 son de Threads, y cualquier herramienta que publique a través de la API oficial trabaja dentro de ellos. Ningún programador sube una cuota de plataforma, así que el trabajo está en la forma de la cola: agrupar medios en carruseles, repartir un lanzamiento a lo largo de varios días y leer quota_usage antes de que salga un lote en lugar de después de que falle una publicación.

El propio consejo de Meta apunta en la misma dirección, ya que pide a las apps que permiten programar posts que apliquen el límite de publicación en local. La mecánica de encolar un post de Threads está cubierta en cómo programar posts en Threads. Ver una semana entera de golpe es lo que evita que se programe una ráfaga, que es el trabajo de un calendario de contenidos, y para quien cargue un mes de una sentada la programación masiva es donde se decide el reparto. AdaptlyPost publica en Threads a través de la API oficial, así que se aplica la misma ventana de 250 posts; la página de la herramienta de programación para Threads explica cómo funciona esa conexión.

Preguntas frecuentes

¿Los posts hechos en la app de Threads cuentan para los 250?

La frase de la página general de Meta limita los perfiles a 250 "API-published posts", lo que nombra los posts creados a través de la API de Threads. La página de carruseles se deja el prefijo "API-" y dice "250 published posts", y Meta nunca dice qué lectura rige. Consulta GET /{threads-user-id}/threads_publishing_limit cuando el volumen de publicación manual sea alto, ya que ese endpoint informa de lo que Meta está contando de verdad.

¿Las respuestas cuentan contra la cuota de 250 posts?

No. Las respuestas tienen un presupuesto aparte de 1.000 dentro de un periodo móvil de 24 horas, informado a través de los campos reply_quota_usage y reply_config del mismo endpoint. Publicar una respuesta nunca reduce los 250 disponibles para posts.

¿Cuándo se reinicia la ventana de 24 horas?

Nunca se reinicia, porque Meta la llama "24-hour moving period". Las publicaciones individuales salen del recuento de una en una, 24 horas después de cada una. El campo quota_duration dice lo mismo en números, 86400 segundos.

¿Cuántas imágenes puede publicar un perfil al día por la API de Threads?

Hasta 5.000, si cada publicación es un carrusel completo. Meta limita un carrusel a 20 hijos y lo cuenta como un solo post, así que 250 publicaciones llevan 250 veces 20 piezas de medios. Publicar imágenes sueltas deja al mismo perfil en 250 imágenes.

¿Crear un contenedor de medios gasta cuota?

Meta afirma que el límite "is enforced on the POST /{threads-user-id}/threads_publish endpoint when attempting to publish a media container", lo que pone el recuento en la llamada de publicación. Los contenedores sí llevan su propio reloj: uno sin publicar devuelve EXPIRED, descrito así: "The container was not published within 24 hours and has expired."

¿Dónde está documentado el límite de 250 posts?

En la página general de Threads de Meta, en developers.facebook.com/documentation/threads/overview, dentro de Rate Limiting, en la subsección Posts. El recorrido de carruseles en developers.facebook.com/documentation/threads/posts repite el número en una nota sobre el paso 3, y el endpoint de cuota que lo informa está documentado tanto en la página de troubleshooting como en la referencia de User.

¿El límite de 250 se aplica al perfil de Threads o a la app?

Los 250 son una cuota a nivel de perfil que pertenece a la propia cuenta de Threads. En paralelo existe un límite de tasa propio para cada app, calculado a partir de impresiones en vez de una cifra fija, así que un perfil puede llegar a sus 250 publicaciones mientras la app conectada todavía tiene bastante margen de llamadas.

¿Puede un desarrollador pedirle a Meta que suba el tope de 250?

La documentación de Meta menciona el número 250 tanto en la página de resumen como en la guía de carruseles, sin describir ninguna vía para solicitar un tope más alto. La única palanca documentada es agrupar medios en carruseles, ya que un carrusel cuenta como un solo post sin importar cuántos de sus 20 hijos posibles lleve. Leer quota_total en vez de fijar 250 en el código es la única preparación que Meta sugiere para el día en que cambie esa cifra.

¿Qué debería hacer una cola de programación si un lote fuera a superar la cuota de 250?

Meta no documenta ningún código de error por superar la cuota de publicación, así que una herramienta que espere a capturar un fallo no tiene nada fiable que atrapar. La propia recomendación de Meta es comprobar quota_usage antes de lanzar un lote y retener publicaciones localmente, justo lo que pide a cualquier app que permite programar posts para el futuro.

¿El límite de 250 posts de Threads es el mismo que el de Instagram?

Las cifras no coinciden. Los perfiles de Threads tienen 250 posts publicados por API dentro de una ventana móvil de 24 horas, mientras que el tope comparable de la API de Instagram es de 100 posts por 24 horas. Ambos límites corren sobre la misma infraestructura de Meta y ambos van acompañados de un límite por app construido con la misma fórmula basada en impresiones.