Como funciona o limite de 250 posts por dia da API do Threads

O que é o limite de 250 posts por dia da API do Threads?

A Meta aplica o limite de 250 posts por dia da API do Threads à etapa de publicação, então um perfil do Threads pode transformar 250 contêineres de mídia em posts ao vivo a cada 24 horas corridas. A frase está na seção Rate Limiting da visão geral do Threads da Meta e diz: "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."

Três detalhes dessa passagem decidem como uma fila se comporta. "API-published" restringe a contagem aos posts enviados pela API do Threads, e não aos digitados no app do Threads. "Moving" descarta um reset à meia-noite. E nomear o threads_publish como ponto de aplicação significa que criar contêiner é de graça, porque a contagem só anda quando um contêiner vira post.

A Meta acrescenta uma quarta frase mirada em quem constrói agendador: "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."

Como funciona a janela de 24 horas?

A janela desliza, e cada publicação sai da contagem 24 horas depois de ter acontecido, e não em um horário fixo. Um perfil que queima os 250 lugares entre 08:00 e 09:00 de segunda recupera essa capacidade entre 08:00 e 09:00 de terça, uma publicação por vez, e não em um bloco único à meia-noite.

O endpoint de cota coloca um número na janela. O objeto config carrega quota_duration: 86400, que são 24 horas em segundos, ao lado de quota_total: 250. Nada na documentação do Threads expõe os timestamps das publicações individuais, então o único jeito de saber quanto espaço resta neste segundo é perguntar à Meta qual é o uso atual.

Qual endpoint informa a cota restante?

O GET /{threads-user-id}/threads_publishing_limit devolve a contagem do próprio perfil, e a Meta o descreve como a forma "To validate that a user has not exhausted their API quota limits for publishing, reply publishing, deleting, and location search." Dois campos cobrem a publicação: quota_usage, que a Meta define como "Threads publishing count over the last 24 hours", e config, que guarda quota_total e 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
      }
    }
  ]
}

A chamada exige as permissões threads_basic e threads_content_publish. Ler o quota_total em vez de cravar 250 no código é a diferença entre uma integração que sobrevive a uma mudança de cota e uma que se estrangula em silêncio por um ano depois de a Meta subir o teto.

Quais são as outras cotas da API do Threads?

O mesmo endpoint informa quatro orçamentos separados, cada um com seu par de campos e seu próprio teto. Todos usam um quota_duration de 86400 segundos.

As respostas ganham orçamento próprio de 1,000, que a Meta enuncia como "Threads profiles are limited to 1,000 replies within a 24-hour moving period." Um bot que responde comentários tem, portanto, quatro vezes mais folga do que um que publica, e gastar cota de resposta nunca encosta nos 250. Nenhum desses orçamentos interage com o teto de 500 caracteres no texto do post, que é aplicado na criação do contêiner e não na publicação, e está coberto em o limite de caracteres do Threads.

Um carrossel conta como um post ou como vinte?

Um carrossel conta como uma publicação, tenha o que tiver dentro. A Meta escreve isso duas vezes: "Carousels count as a single post" na página de visão geral, e "Publishing a carousel counts as a single post" no passo a passo do carrossel. Como um carrossel do Threads aceita até 20 filhos, um perfil que publica só carrosséis cheios move 5,000 imagens e vídeos em 250 publicações.

Essa proporção é a única alavanca real que alguém tem sobre esse teto. Dez imagens separadas custam dez dos 250 lugares. As mesmas dez enviadas como um carrossel custam um. Quem está perto do teto deveria estar agrupando mídia antes de pedir mais folga, que é a mesma aritmética por trás do limite de 100 posts por 24 horas da API do Instagram.

Por que as duas páginas da Meta descrevem o mesmo limite de formas diferentes?

O número bate entre as páginas e a redação não. A página de visão geral diz "250 API-published posts within a 24-hour moving period". O passo a passo do carrossel, em uma nota acima do Step 3, diz "Profiles are limited to 250 published posts within a 24-hour period."

A segunda versão derruba o "API-" e derruba o "moving". Lida ao pé da letra, cobriria posts feitos à mão no app e zeraria em um relógio fixo. A Meta nunca concilia as duas, e só a página de visão geral carrega o detalhe de aplicação que nomeia o threads_publish, então a visão geral é o enunciado mais completo da mesma regra. Trate a frase curta como uma abreviação, e não como uma segunda política.

Que erro o Threads devolve quando a cota acaba?

A Meta não documenta nenhum código de erro para estouro da cota de publicação. O índice da Threads API Reference lista nove páginas de endpoint e nenhuma página de códigos de erro, e a página de troubleshooting só cobre resultados de contêiner: os valores de status EXPIRED, ERROR, FINISHED, IN_PROGRESS e PUBLISHED, mais valores de error_message de vídeo como FAILED_DOWNLOADING_VIDEO e INVALID_ASPEC_RATIO.

A única string de falha na publicação que a Meta documenta não tem nada a ver com volume. A partir de 22 de dezembro de 2025, um post com mais de cinco links falha na etapa do contêiner com THREADS_API__LINK_LIMIT_EXCEEDED. Não existe constante equivalente para os 250.

Essa ausência é o motivo de a Meta pedir que os apps apliquem o limite por conta própria. Código escrito contra uma resposta de falha não documentada é chute; código que lê o quota_usage antes de publicar está consultando o mesmo contador que a Meta.

Em que o rate limit por app difere dos 250?

Os 250 são um orçamento de publicação no nível do perfil. À parte, toda chamada à API do Threads conta contra o app que chama, e a Meta dá a isso uma fórmula em vez de uma constante: Calls within 24 hours = 4800 * Number of Impressions, em que impressões são "the number of times any content from the app user's Threads account has entered a person's screen within the last 24 hours". O valor mínimo de impressões é 10, então o piso é de 48,000 chamadas por par de app e usuário.

Dois orçamentos de CPU vêm junto, 720000 * number_of_impressions para tempo total de CPU e 2880000 * Number of Impressions para tempo total. O mesmo formato baseado em impressões rege o limite de taxa de 4800 impressões da API do Instagram, o que não surpreende dado que os dois rodam na infraestrutura da Meta.

Um perfil pode, portanto, bater nas 250 publicações estando longe do orçamento de chamadas do app, já que consultar status de contêiner, ler insights e buscar respostas gastam chamadas sem gastar publicações.

O que o teto significa para uma fila de agendamento?

Os 250 pertencem ao Threads, e toda ferramenta que publica pela API oficial trabalha dentro deles. Nenhum agendador levanta uma cota de plataforma, então o trabalho está no formato da fila: agrupar mídia em carrosséis, espalhar um lançamento por vários dias e ler o quota_usage antes de um lote disparar, em vez de depois de uma publicação falhar.

O conselho da própria Meta aponta para o mesmo lado, já que ela pede que apps que deixam as pessoas agendar posts apliquem o limite de publicação localmente. A mecânica de enfileirar um post do Threads está coberta em como agendar posts no Threads. Ver uma semana inteira de uma vez é o que impede um pico de ser agendado, que é a função de um calendário de conteúdo, e para quem carrega um mês de uma sentada o agendamento em massa é onde a distribuição se decide. A AdaptlyPost publica no Threads pela API oficial, então vale a mesma janela de 250 posts; a página da ferramenta de agendamento para Threads explica como essa conexão funciona.

Perguntas frequentes

Posts feitos no app do Threads contam para os 250?

A frase da visão geral da Meta limita perfis a 250 "API-published posts", o que nomeia posts criados pela API do Threads. A página do carrossel derruba o prefixo "API-" e diz "250 published posts", e a Meta nunca diz qual leitura vale. Consulte o GET /{threads-user-id}/threads_publishing_limit quando o volume de postagem manual for alto o bastante para importar, já que esse endpoint informa o que a Meta está de fato contando.

Respostas contam contra a cota de 250 posts?

Não. Respostas têm um orçamento separado de 1,000 dentro de um período móvel de 24 horas, informado pelos campos reply_quota_usage e reply_config no mesmo endpoint. Publicar uma resposta nunca reduz os 250 disponíveis para posts.

Quando a janela de 24 horas zera?

Ela nunca zera, porque a Meta a chama de "24-hour moving period". Cada publicação sai da contagem uma a uma, 24 horas depois de ter acontecido. O campo quota_duration diz a mesma coisa numericamente, como 86400 segundos.

Quantas imagens um perfil pode publicar por dia pela API do Threads?

Até 5,000, se toda publicação for um carrossel cheio. A Meta limita um carrossel a 20 filhos e o conta como um post só, então 250 publicações carregam 250 vezes 20 peças de mídia. Publicar imagens avulsas limita o mesmo perfil a 250 imagens.

Criar um contêiner de mídia gasta cota?

A Meta afirma que o limite "is enforced on the POST /{threads-user-id}/threads_publish endpoint when attempting to publish a media container", o que põe a contagem na chamada de publicação. Contêineres têm relógio próprio: um contêiner não publicado devolve EXPIRED, descrito como "The container was not published within 24 hours and has expired."

Onde o limite de 250 posts está documentado?

Na página de visão geral do Threads da Meta, em developers.facebook.com/documentation/threads/overview, sob Rate Limiting, na subseção Posts. O passo a passo do carrossel em developers.facebook.com/documentation/threads/posts repete o número em uma nota acima do Step 3, e o endpoint de cota que o informa está documentado tanto na página de troubleshooting quanto na referência de User.

O limite de 250 vale para o perfil do Threads ou para o app?

Os 250 são uma cota no nível do perfil, ligada à própria conta do Threads. Em paralelo existe um rate limit próprio para cada app, calculado a partir de impressões em vez de um número fixo, então um perfil pode chegar às suas 250 publicações enquanto o app conectado ainda tem bastante margem de chamadas.

Um desenvolvedor pode pedir à Meta para elevar o teto de 250?

A documentação da Meta cita o número 250 tanto na página de visão geral quanto no guia de carrossel, sem descrever nenhum caminho para pedir um teto maior. A única alavanca documentada é agrupar mídia em carrosséis, já que um carrossel conta como um único post não importa quantos dos seus 20 filhos possíveis carregue. Ler quota_total em vez de fixar 250 no código é a única preparação que a Meta sugere para o dia em que esse número mudar.

O que uma fila de agendamento deveria fazer quando um lote for ultrapassar a cota de 250?

A Meta não documenta nenhum código de erro para quem ultrapassa a cota de publicação, então uma ferramenta que espera capturar uma falha não tem nada confiável para pegar. A própria recomendação da Meta é checar quota_usage antes de disparar um lote e segurar posts localmente, exatamente o que ela pede a qualquer app que deixe agendar posts futuros.

O limite de 250 posts do Threads é igual ao do Instagram?

Os números são diferentes. Perfis do Threads têm 250 posts publicados pela API dentro de uma janela móvel de 24 horas, enquanto o teto comparável da API do Instagram é de 100 posts por 24 horas. Os dois limites rodam na mesma infraestrutura da Meta e cada um vem acompanhado de um limite por app construído com a mesma fórmula baseada em impressões.