Limites de taxa da API de redes sociais: o que planejar

Se você publica de forma programática, dois limites de taxa separados se aplicam e apenas um deles está sob seu controle.

Os dois níveis

O limite da plataforma. Toda rede social limita quanto qualquer aplicativo pode fazer na sua API, com sua própria janela, seus próprios cabeçalhos e seu próprio comportamento quando excedido. Eles diferem por plataforma e mudam sem muito aviso.

O limite do seu provedor. Se você publica por meio de uma API unificada, esse serviço também tem um limite, geralmente vinculado ao seu plano.

O segundo é fácil de ler e planejar. O primeiro é o que morde, porque você nunca o vê diretamente se estiver usando uma API unificada. O provedor absorve isso, o que é boa parte do que você está pagando, mas não desaparece: uma plataforma restringindo todo mundo ainda significa que seu post fica atrasado.

Projete para o atraso, não só para os erros

O erro mais comum em um pipeline de publicação é tratar “aceito” como “publicado”.

Em várias plataformas, submeter um post retorna sucesso e a publicação de fato acontece depois. Então a falha chega mais tarde, fora de banda, muito depois de sua requisição ter retornado 200. Se o seu modelo de dados só tem “enviado” e “falhou”, não há onde colocar “achamos que isso está sendo publicado”.

Projete para três estados, e torne o pendente visível.

Regras práticas

Recue exponencialmente. Em um 429, espere e tente de novo com um atraso crescente. Retentativas imediatas pioram a situação e podem prolongar um bloqueio.

Limite suas retentativas. Um pipeline tentando de novo para sempre é como uma cota desaparece em minutos. Desista, registre em voz alta e deixe um humano olhar.

Nunca refaça uma criação às cegas. Se uma requisição de criação expira, você não sabe se ela teve sucesso. Tentar de novo pode produzir posts duplicados, o que é pior do que a falha original. Verifique antes de tentar de novo, ou use uma abordagem que torne a nova tentativa segura.

Faça lote onde um endpoint suportar. Uma requisição criando muitos posts custa uma requisição. O mesmo trabalho como cinquenta chamadas individuais custa cinquenta.

Os próprios limites do BulkPublish

As 30 requisições por dia do plano gratuito são deliberadamente dimensionadas para avaliar a API e rodar algo leve e pessoal. Não são suficientes para rodar um pipeline de verdade, e um loop sem backoff vai esgotá-las em segundos.

Observe que requisições de API e posts são limites separados. Listar canais, verificar status e enviar mídia consomem requisições sem criar um post, então o orçamento de requisições rende mais do que a contagem de posts sugere, só se você usá-lo com cuidado.

Várias chaves servem para separação, não mais capacidade

Os planos pagos incluem várias chaves de API, e o motivo não é mais throughput. É para que coisas diferentes possam ter credenciais diferentes: seu pipeline de produção, um ambiente de staging, um agente de IA.

O valor aparece quando algo dá errado. Você revoga uma chave às 2h da manhã em vez de girar a única credencial que tudo compartilha.

Um formato sensato para um job de publicação

1. Consulte os canais uma vez na inicialização, não por post
2. Envie a mídia, depois crie os posts referenciando os ids
3. Use endpoints em lote onde existirem
4. Trate 429 com backoff exponencial e um teto de retentativas
5. Registre toda falha com o corpo da resposta, porque ninguém está observando

A versão curta

Dois limites se aplicam: o da plataforma, que você não consegue ver por meio de uma API unificada, e o do seu provedor, que você consegue. Recue exponencialmente, limite as retentativas, nunca refaça uma criação às cegas. E trate “aceito” como um estado distinto de “publicado”, porque em várias plataformas isso é genuinamente verdade.