Você subiu um chatbot no WhatsApp Business API. As primeiras semanas foram tranquilas. Aí de repente o número foi banido. Sem aviso. Sem recurso claro. A linha sumiu, o cliente sumiu junto, e você está olhando para um 401 Unauthorized com a sensação de ter perdido um ativo que levou meses para construir.
Isso acontece mais do que você imagina. E na maioria dos casos, não é falha do provedor nem azar — é uma falha de governança no comportamento do agente.
Por que o WhatsApp detecta e bloqueia automações
O WA mantém um Health Score por número que combina sinais comportamentais e sinais de rede. Ele não olha só o conteúdo — analisa o padrão de uso.
1. Taxa de envio fora do perfil humano
Um humano raramente envia mais de 20 mensagens em 5 minutos para contatos diferentes. Um bot sem throttling pode atingir 200. O WA identifica isso como blast e aplica throttle progressivo — que, sem correção, vira suspensão.
2. Latência de resposta determinística
Humanos têm variação natural: às vezes respondem em 3 segundos, às vezes em 40. Bots sem randomização respondem em ~1.2s sempre. Esse padrão é detectável por análise estatística simples.
3. Taxa de rejeição de template acima de 2%
Se os destinatários estão bloqueando ou denunciando seus HSMs com frequência acima de 2%, o número entra em zona de risco. A Meta publica esse threshold na documentação oficial.
4. Sessões inconsistentes
Para on-premise (Baileys, WWEBJS): trocar de IP em sessão ativa ou abrir sessões paralelas com o mesmo número gera fingerprint inconsistente — o WA trata como comprometimento de conta.
5. Ausência de opt-out real
Enviar para quem nunca consentiu ou não ter mecanismo de saída gera denúncias. Denúncia é o sinal com maior peso no Health Score.
5 práticas concretas para manter a linha saudável
1. Jitter obrigatório entre envios
Nunca envie em cadência fixa. Adicione variação aleatória:
import random
import time
def send_with_jitter(
client,
to: str,
message: str,
base_delay: float = 2.0,
jitter_range: float = 1.5,
) -> dict:
"""Envia mensagem com delay variável para simular comportamento humano."""
delay = base_delay + random.uniform(0, jitter_range)
time.sleep(delay)
return client.send_message(to=to, body=message)
Para campanhas em volume, respeite também o fuso do destinatário — enviar às 2h da manhã é outro sinal negativo.
2. Opt-out com efeito imediato na fila
O opt-out não pode ser decorativo. Precisa interromper imediatamente qualquer envio futuro, incluindo mensagens já agendadas:
def handle_opt_out(phone: str, db_conn) -> None:
"""
Registra opt-out e cancela filas pendentes.
Deve ser chamado ANTES de qualquer outra lógica de resposta.
"""
db_conn.execute(
"UPDATE contacts SET opted_out_at = NOW() WHERE phone = %s",
(phone,),
)
db_conn.execute(
"DELETE FROM message_queue WHERE to_phone = %s AND sent_at IS NULL",
(phone,),
)
db_conn.commit()
Palavras como PARAR, SAIR, STOP, CANCELAR precisam ser interceptadas antes do processamento pelo LLM. Nunca deixe o modelo decidir o que fazer com um opt-out.
3. Health Score monitoring via API do Manager
A Meta expõe o Health Score via Graph API. Crie um cron simples que alerta quando o score degradar:
import requests
def check_health_score(waba_id: str, access_token: str) -> dict:
url = f"https://graph.facebook.com/v19.0/{waba_id}"
response = requests.get(url, params={
"fields": "health_status",
"access_token": access_token,
})
return response.json().get("health_status", {})
# health_status.can_send_message == "AVAILABLE" → estado seguro
# health_status.can_send_message == "LIMITED" → pare envios proativos
# health_status.can_send_message == "BLOCKED" → só suporte Meta resolve
4. Sessões isoladas por número
No modelo on-premise, cada número precisa de isolamento completo:
/sessions/
+5511999990001/
session.json
auth_info/ ← pasta exclusiva deste número
+5511999990002/
session.json
auth_info/
IP dedicado por sessão, processo independente. Nunca compartilhe contexto de sessão entre números.
5. Janela de mensagem vs. template
O WA tem dois contextos: dentro da janela de 24h (mensagem livre) e fora dela (obrigatório HSM aprovado). Bots que tentam mensagem livre fora da janela geram erro 131047. Erro repetido degrada o Health Score.
from datetime import datetime, timedelta
def get_message_type(last_user_message_at: datetime) -> str:
"""Retorna o tipo de mensagem permitida com base na janela de 24h."""
window_open = datetime.utcnow() - last_user_message_at < timedelta(hours=24)
return "session_message" if window_open else "template"
A raiz do problema: agente sem halt automático
As cinco práticas acima resolvem sintomas. O problema estrutural é mais profundo: um agente autônomo sem audit trail e sem mecanismo de halt não tem como ser contido quando começa a errar.
Governança de agente significa que cada decisão do LLM — enviar mensagem, acionar ferramenta, escalar para humano — passa por uma camada que registra, avalia e pode interromper. Isso inclui:
- Audit trail imutável: cada mensagem tem registro de qual decisão do agente a gerou, com confiança e contexto
- Rate limiter por agente, separado do rate limit do número: o agente pode ser contido sem derrubar a sessão WA
- Fallback automático para humano: quando o agente detecta incerteza alta, entrega o contexto para um atendente em vez de alucinar
-
Halt imediato em rejeição WA: qualquer
401/403da API dispara parada completa do agente — sem retry, sem backoff, sem "só mais uma vez"
Esse último ponto é crítico e frequentemente ignorado. Agentes com loop de reconexão agressivo são dos principais vetores de banimento definitivo.
Regra de ouro: reputação de número de WhatsApp é ativo não-recuperável. Uma vez queimada via fingerprinting agressivo, o número está perdido. Governança não é opcional em produção.
Conclusão
A maioria dos banimentos de WhatsApp não é inevitável. Eles resultam de três padrões evitáveis: cadência sem jitter, opt-out decorativo e agentes sem mecanismo de halt.
Implemente as cinco práticas acima antes de colocar qualquer automação em produção com volume relevante. E, independente da stack que você usar, trate a camada de governança do agente como componente separado da infraestrutura WA — é uma decisão de arquitetura, não de configuração.
Construindo algo parecido? A Mukta API oferece orquestração de agentes autônomos com essas garantias embutidas — audit trail, trust-tier, halt automático em rejeição WA — sobre qualquer provider (Meta Cloud, Twilio ou on-premise). Plano self-service a partir de R$100/mês.
Top comments (0)