Como o WhatsApp detecta disparo em massa

O número tinha três anos de grupo aquecido. Numa quarta de manhã você abre o painel e a sessão está morta, statusCode 401, e no celular aparece "este número não tem permissão para usar o WhatsApp". Nenhum aviso, nenhum email, nenhum motivo. Você tinha subido de 300 pra 900 mensagens por dia na semana anterior, achou que estava tranquilo porque colocou um delay de 3 segundos entre cada envio, igual o vídeo mandou.

Aí você vai pesquisar e encontra a mesma coisa em cinco abas: "não use listas compradas", "aqueça o chip", "varie a mensagem", "respeite o horário comercial". Nenhum desses posts explica por que. Nenhum diz qual dado o servidor está olhando, nem em qual momento, nem qual erro corresponde a qual tipo de restrição. É dica de sobrevivência passada de boca em boca, não mecanismo.

Este post é o mecanismo. Não tem lista de dica, tem os sinais que o sistema antiabuso da Meta usa, o que está documentado publicamente, o que é inferência honesta minha, e o que a sua pilha (Baileys, Evolution, Cloud API) muda em cada camada. Vale avisar de uma vez: nada disso é "método pra nunca ser banido". Depois de entender o mecanismo você vai ver que boa parte das dicas mais repetidas mexe na camada errada.

A resposta curta: como o WhatsApp detecta disparo em massa

Não existe um "detector de disparo". Existem três camadas independentes de avaliação, e cada uma olha uma coisa diferente:

Camada 1, quem está falando. Avaliada no registro e na conexão: reputação do número, reputação da rede/IP de onde ele foi registrado, e se o cliente que abriu a conexão é um cliente autorizado.
Camada 2, a forma do tráfego. Velocidade, regularidade, proporção entre mensagem enviada e recebida, proporção de destinatários que não têm você salvo, repetição de conteúdo.
Camada 3, a reação de quem recebeu. Bloqueio, denúncia, opt-out. É a camada que mais pesa e a que quase nenhum tutorial trata como técnica.

Qual camada te pega depende da pilha. Com Baileys ou Evolution API você está dentro do sistema antiabuso do WhatsApp consumidor, então as três camadas valem, o julgamento é opaco e a punição é binária (a sessão morre). Com a Cloud API a camada 1 praticamente desaparece (você é cliente autorizado por definição) e a camada 2 deixa de ser suspeita pra virar quota explícita com código de erro. A camada 3 continua igual nas duas, e é lá que a maioria morre.

Camada 1: reputação de número, de rede e de cliente

O único documento em que a própria WhatsApp descreve o mecanismo com alguma granularidade é o whitepaper "Stopping Abuse: How WhatsApp Fights Bulk Messaging and Automated Behavior", de 2019. É antigo, mas é primário, e o desenho geral continua valendo. Dois pontos dele importam aqui.

O primeiro: cerca de 20% dos banimentos acontecem no momento do registro, antes da conta mandar uma única mensagem. O que o modelo olha nesse instante é se aquele número (ou um número parecido, da mesma faixa) foi abusado recentemente, e se a rede usada pra registrar já esteve associada a comportamento suspeito. Isso explica a frase que mais aparece em reclamação: "chip novo, banido sem eu nem ter usado". Não é bug, é reputação herdada. Chip requentado comprado de terceiro é exatamente isso: você paga pra herdar histórico que você não pode auditar.

O segundo: a intensidade de atividade logo depois do registro é sinal por si só. Conta nova que já acorda mandando é o padrão mais fácil de pegar do sistema todo, porque conta nova de gente real quase nunca faz isso.

O que o cliente conta sobre você na conexão

No WhatsApp multidevice a conta continua registrada no aparelho, e o Baileys entra como dispositivo companheiro (aquele slot de dispositivo vinculado que você autoriza com QR code ou código de pareamento). Ele não roda navegador nem Selenium: abre um WebSocket direto e faz o handshake do protocolo do WhatsApp Web na mão.

Nesse handshake vai um payload de identificação de cliente: plataforma, versão do WhatsApp Web, identificação de browser. Não é opcional, é parte do protocolo. E é por isso que biblioteca não oficial precisa acompanhar a versão do WA Web real: um cliente que se apresenta com combinação de versão e plataforma que não existe na natureza é um cliente distinguível de um WhatsApp Web de verdade.

Aqui eu preciso ser honesto sobre onde acaba o documentado e começa a inferência. A Meta nunca publicou "usamos o campo X do handshake pra banir". O que é público e verificável são duas coisas: (a) a própria WhatsApp confirma que detecta e bane contas usando clientes modificados, tipo GB WhatsApp e WhatsApp Plus, com a mensagem in-app de "conta temporariamente banida" quando a pessoa não está no app oficial; e (b) o repositório do Baileys tem issues de ban permanente em cenários específicos, inclusive de ban ao usar recursos que o cliente implementa de forma diferente do app real. Junte os dois: a superfície de fingerprint existe e é usada. Só não existe tabela pública dizendo qual byte custou o seu chip.

Camada 2: a assinatura do seu tráfego

O whitepaper resume a heurística central numa frase que vale mais que qualquer lista de dicas: usuário normal opera relativamente devagar, tocando uma mensagem por vez. Toda detecção de padrão nasce disso. O que o servidor vê não é "ele mandou muito", é "esse fluxo não tem forma de humano".

Olhe o loop que praticamente todo mundo escreve na primeira versão:

for (const numero of lista) {
  await sock.sendMessage(numero, { text: msg })
  await sleep(3000)               // "delay pra não ser banido"
}

Do lado do servidor, esse loop produz um conjunto de propriedades estatísticas bem específico: 900 envios com delta de 3000 ms e variância quase zero, conteúdo idêntico ou quase, taxa de resposta perto de zero, e a maior parte dos destinatários sem você na lista de contatos. Ser humano não tem variância zero. Nem ser humano ocupado, nem ser humano rápido. O sleep fixo não te protege, ele te assina, porque regularidade perfeita é mais artificial que velocidade.

Os sinais dessa camada, na prática, são combinatórios:

Razão enviado/recebido. Conversa real é bidirecional. Um número que fala com 900 pessoas e recebe resposta de 12 tem uma forma de tráfego que nenhum atendimento legítimo tem.
Proporção de destinatários que não te têm salvo. Sinal clássico de lista fria, citado no whitepaper e reforçado em todo material posterior da plataforma.
Similaridade de conteúdo. Não é só texto igual: mudar "olá {nome}" no começo e manter o resto idêntico continua sendo o mesmo corpo de mensagem pra qualquer medida de similaridade decente.
Regularidade temporal. Delta constante, e volume que não respeita ritmo circadiano nenhum.
Aceleração. Ir de 300 pra 900 num dia é uma derivada, e derivada é fácil de medir. A escada é mais suspeita que o degrau.

No lado do consumidor nada disso tem número público, por design: se a Meta publicasse o limiar, todo mundo operaria logo abaixo dele. Já no lado da API oficial a mesma camada existe, mas documentada e com número, o que é ótimo pra raciocinar. A Cloud API tem throughput padrão de 80 mensagens por segundo por número, com upgrade até 1000 mps pra quem se qualifica, e tiers de destinatários únicos por dia (250 no padrão, subindo por 2 mil, 10 mil, 100 mil, até ilimitado). Desde outubro de 2025 esses limites são calculados no nível do portfólio de negócios, não por número, então adicionar um segundo número no mesmo portfólio não dobra a capacidade. A reavaliação pra subir de tier roda a cada 6 horas.

E quando você bate na parede, o erro te diz exatamente qual camada reclamou:

130429  Cloud API message throughput has been reached
        (você estourou o mps: backoff exponencial, não é castigo)

131056  Too many messages sent from the sender phone number
        to the same recipient phone number in a short period
        (pair rate limit: é por PAR, outros destinatários seguem)

131047  More than 24 hours have passed since the recipient
        last replied (janela fechada: só template resolve)

131048  Message failed to send because there are restrictions
        on how many messages can be sent from this phone number
        (spam rate limit: aqui é qualidade, não velocidade)

Esses quatro são coisas diferentes e muita gente trata todos como "fui limitado". 130429 é técnico e some sozinho. 131056 é de par, não global. 131047 é regra de janela. Só o 131048 é castigo de reputação, e ele nasce na camada 3.

Detalhe operacional que morde muita gente: retry cego em 130429 é o jeito mais rápido de mandar a mesma mensagem duas vezes pro mesmo lead, porque parte das falhas de throughput acontece depois do aceite. Backoff exponencial resolve o rate limit, mas a duplicata só a chave de idempotência resolve, e eu já detalhei esse desenho em idempotência em webhook.

Camada 3: quem recebeu decide seu destino

Essa é a camada que os posts de dica tratam como detalhe e que os dados mostram ser a principal. Os relatórios mensais que a WhatsApp publica na Índia por obrigação regulatória dão a proporção: em junho de 2026 foram 5.104.127 contas banidas no país, das quais 1.369.080 (cerca de 27%) foram banidas proativamente, antes de qualquer denúncia de usuário. Ou seja, aproximadamente três de cada quatro banimentos envolveram reclamação humana no caminho.

Traduzindo pro seu caso: a detecção puramente algorítmica existe e é grande, mas a maioria das contas cai porque as pessoas do outro lado bloquearam ou denunciaram. Isso reordena a prioridade inteira. Não é "quão rápido eu mando", é "pra quem eu mando e o quanto essa pessoa esperava a minha mensagem". Um disparo lento, humanizado, com delay aleatório e cinco variações de texto, pra uma lista que nunca pediu nada, continua indo pro mesmo lugar. É por isso que "aquecer o chip" conversando com amigos não funciona como as pessoas acham: aquecimento mexe na camada 1 e 2, e não muda em nada o comportamento de quem recebe seu disparo depois.

Na API oficial essa camada é exposta com nome e cor. O quality rating (verde, amarelo, vermelho) é calculado a partir de bloqueio, denúncia e opt-out dos últimos envios, e mede reação, não volume. Rating baixo hoje não rebaixa mais o seu limite automaticamente (a Meta removeu o status "Flagged"), mas trava a subida de tier e, no fundo do poço, aparece como 131048. Template com qualidade ruim é pausado. E existe o limite por usuário de template de marketing, que é um teto de quantas mensagens de marketing uma pessoa recebe por dia somando todas as marcas: quer dizer que a caixa de entrada do seu lead tem orçamento finito e você compete por ele com todo mundo.

Quando a conta é restringida de vez, o erro muda de natureza: 368 e 131031 significam conta de WhatsApp Business restrita ou desabilitada por violação de política. Não é rate limit. Não passa com backoff.

Por que a Cloud API muda o jogo (e onde não muda)

Na Cloud API o número é registrado na infraestrutura da Meta, não num aparelho seu, e você não pode ter o app instalado com aquele número ao mesmo tempo. Consequência direta: não existe cliente pra fazer fingerprint, não existe sessão pra cair, não existe QR code pra reconectar de madrugada. Você troca detecção opaca por quota documentada, código de erro, e um painel com quality rating e Health Status API pra consultar o motivo de bloqueio.

O que você paga por isso, honestamente: custo por mensagem de template, aprovação de template (você não manda o texto que quiser), janela de 24 horas pra mensagem livre, e processo de verificação de negócio. E o mais importante de tudo: API oficial não é imunidade. Ela te tira das camadas 1 e 2 e te deixa exatamente igual a todo mundo na camada 3. Lista comprada com API oficial vira rating vermelho, template pausado e 131048, só com nota fiscal.

Do outro lado, Baileys e Evolution API são grátis, flexíveis e mandam qualquer coisa pra qualquer número, sem template e sem aprovação. O preço é estar dentro do sistema antiabuso do consumidor, onde não existe SLA, não existe código de erro explicativo e não existe recurso técnico quando cai. Eu comparei os três caminhos com custo e risco em Evolution API vs Cloud API vs Baileys; aqui só reforço a parte de protocolo: são regimes de enforcement diferentes, não versões caras e baratas da mesma coisa.

Instrumentar pra ler o sinal antes do ban

Quem roda biblioteca não oficial não recebe aviso, mas recebe sintoma. E o sintoma mais barato de instrumentar é a própria desconexão. No Baileys, o statusCode do lastDisconnect é o que separa "caiu, reconecta" de "morreu, para de tentar":

sock.ev.on('connection.update', ({ connection, lastDisconnect }) => {
  if (connection !== 'close') return

  const code = lastDisconnect?.error?.output?.statusCode

  // 401 loggedOut  = sessão invalidada (ban ou desvínculo no aparelho)
  // 403 forbidden  = conexão recusada, costuma ser terminal
  if (code === 401 || code === 403) {
    alerta(`sessao terminal (${code}): reconectar em loop nao resolve`)
    return                       // exige novo pareamento, ou o número foi embora
  }

  // 428 connectionClosed, 440 connectionReplaced, 515 restartRequired
  reconectar()                   // transiente: backoff e volta
})

Loop de reconexão cego em 401 é um clássico: o número já está morto e a sua VPS fica batendo no endpoint por horas, o que não ajuda a reputação da rede (camada 1) e faz você descobrir o problema pelo cliente reclamando. Além do statusCode, três métricas simples que valem mais que qualquer checklist de anti-ban:

Taxa de resposta por lote. É o proxy mais próximo do que a camada 2 mede. Se caiu de 8% pra 1% entre lotes, sua lista degradou antes do seu número.
Não entregues do lote. Mensagem que fica em um check só, em massa, indica bloqueio acumulado e antecipa a camada 3.
Contagem de reconexões por hora. Se subiu sem você mexer em nada, a sessão está sendo empurrada, e isso costuma vir antes do 401.

E, óbvio, isso só serve se o alerta chegar em você. Se o seu monitoramento depende de um webhook que ninguém testou, você vai descobrir tudo isso depois do fato, que é o assunto de por que seu webhook do WhatsApp não dispara.

O que dá errado

Erros que eu já cometi ou vi de perto nessa análise:

Achar que é só velocidade. Velocidade é um sinal entre vários e não é o mais pesado. Mandar devagar pra lista fria é ser banido devagar.
Tratar delay aleatório como feitiço. Randomizar intervalo mexe numa propriedade real (variância), mas não muda destinatário, conteúdo nem taxa de resposta. Sozinho, muda pouco.
Trocar de chip mantendo o padrão. Se o registro sai da mesma rede, com o mesmo cliente, pro mesmo tipo de lista, você reinicia a camada 3 e não reinicia a camada 1. Costuma cair mais rápido que o anterior.
Concentrar instância em IP sujo. Faixa de datacenter compartilhada com dezenas de instâncias fazendo a mesma coisa é reputação de rede que você não controla e não vê.
Ler 131048 como limite técnico. Não é. É recado de qualidade. Aumentar o delay não resolve; consertar quem entra na lista resolve.
Confiar em número novo no mesmo portfólio. Desde outubro de 2025 o limite é do portfólio, então "abrir outro número" não é a saída que era.
Acreditar em "0% de ban". Nenhum fornecedor controla as camadas 1, 2 e 3. Quem promete isso está te vendendo a parte que ele controla e escondendo o resto.
Confundir número com processo. Todo número que você usa pra falar com quem não pediu é descartável. A pergunta certa não é como blindar o chip, é quanto do seu faturamento morre junto com ele.

Fechando

Como o WhatsApp detecta disparo em massa, resumido: ele avalia quem se conectou (número, rede, cliente), a forma do fluxo (velocidade, regularidade, reciprocidade, similaridade) e a reação de quem recebeu (bloqueio, denúncia, opt-out). A terceira camada é a que decide a maioria dos casos, e é a única que não muda quando você troca de pilha, de chip ou de fornecedor. Trocar Baileys por Cloud API muda o regime de punição de "sessão morre sem explicação" pra "código de erro e rating", o que é uma melhora enorme de operação e nenhuma melhora de permissão.

A conclusão prática é meio ingrata e por isso quase nunca aparece nos posts de dica: nenhum ajuste de protocolo compensa mandar mensagem pra quem não quer receber. O trabalho de verdade é do lado da lista e do consentimento. O protocolo só é o lugar onde a conta chega.

Fontes primárias consultadas: whitepaper "Stopping Abuse: How WhatsApp Fights Bulk Messaging and Automated Behavior" (WhatsApp, 2019); documentação de Messaging Limits e de Error Codes da WhatsApp Business Platform (Meta for Developers); relatórios mensais de compliance da WhatsApp na Índia (IT Rules, 2021), edição de junho de 2026; repositório e issues do WhiskeySockets/Baileys; central de ajuda da WhatsApp sobre aplicativos não autorizados. Limiares do WhatsApp consumidor não são publicados pela Meta e o que está marcado como inferência no texto é inferência.