Erro 463 do WhatsApp e o reachout timelock: o que significa

O erro 463 do WhatsApp é o que uma biblioteca como Baileys ou WAHA recebe quando o WhatsApp recusa o envio de uma mensagem porque a conta está sob um reachout timelock: uma restrição temporária para iniciar conversas com pessoas com quem ela nunca falou. Os chats que já existem continuam funcionando, e a restrição acaba sozinha. O WhatsApp descreve a restrição, mas nunca menciona o código.

Como o erro 463 aparece nos seus logs?

O erro 463 aparece com nomes diferentes conforme a biblioteca. O whatsmeow e o engine GOWS do WAHA devolvem server returned error 463. O Baileys recebe um ack da mensagem com error='463' e grava messageStubParameters: ["463"]. A Evolution API, que envolve o Baileys, muitas vezes não mostra nada além de uma mensagem presa em PENDING depois de a chamada HTTP ter dado certo, então o código só aparece com LOG_BAILEYS=trace, como um usuário relatou na thread de investigação do Baileys.

Os primeiros relatos públicos que encontramos são de 12 de fevereiro de 2026 (issue 1074 do whatsmeow). Os mantenedores do Baileys abriram a investigação em 25 de março de 2026, e o relato sobre o GOWS do WAHA veio em 31 de março de 2026. Ele ainda estava aberto em 19 de outubro de 2026.

O que o próprio WhatsApp confirma?

A página de ajuda do WhatsApp Sobre contas restritas confirma o comportamento sem nomear o erro. Uma conta pode ver no app a mensagem “Sua conta está restrita agora” ou um aviso de que pode ser restrita em breve. A página diz:

• A restrição termina automaticamente depois de um tempo definido, e o WhatsApp envia uma notificação quando isso acontece.
• Para ver o tempo restante, toque em Nova conversa e escolha um contato com quem você nunca conversou.
• A causa é atividade recente que pode mostrar sinais de spam, de mensagens automáticas ou em massa.
• Você ainda pode se comunicar com contatos e grupos com quem já trocou conversas ou chamadas.
• Você não pode iniciar conversas ou chamadas com novos contatos, criar grupos, adicionar participantes a grupos nem usar dispositivos conectados, e pode ser desconectado de alguns dispositivos complementares.

Uma segunda página, Como usar o WhatsApp com responsabilidade, orienta as pessoas a mandar mensagem só para quem as contatou primeiro ou pediu para ser contatado. Acrescenta que o WhatsApp usa machine learning e denúncias de usuários para detectar mensagens automáticas indesejadas.

O WhatsApp não publica o código 463, a palavra “timelock”, limiares nem durações. A referência de erros da Cloud API da Meta também não lista o 463.

O que os desenvolvedores descobriram?

Desenvolvedores associaram o 463 à restrição lendo o próprio código do WhatsApp Web. É engenharia reversa bem fundamentada, não documentação. As principais descobertas:

• O nome. Um mantenedor do Baileys encontrou NackCallerReachoutTimelocked: 463 no WhatsApp Web, além de uma consulta que retorna se o bloqueio está ativo, o tipo e o horário de término (Baileys 2441, 25 de março de 2026).
• O que o bloqueio barra. O código do cliente deixa uma conta restrita mandar mensagem para si mesma, contas comerciais, contas de suporte, bots e qualquer chat para o qual ela tenha um token de contato confiável (tctoken). O WhatsApp distribui esse token de privacidade conforme duas contas trocam mensagens. Um chat novo não tem nenhum, o que bate com a página de ajuda do WhatsApp.
• Os tipos. O Baileys traz um enum de tipos de sanção lido do cliente web. Inclui WEB_COMPANION_ONLY, BIZ_QUALITY e 15 valores BIZ_COMMERCE_VIOLATION_*, e o WAHA lista também RESTRICT_ALL_COMPANIONS. Isso sugere uma ferramenta geral de sanção, não só um limite de volume (uma inferência).
• Um bug nas bibliotecas piorou a situação. A hipótese dos mantenedores era que envios sem tokens de privacidade contavam para o limite. Vieram correções: os pull requests 2257 (mesclado em 17 de janeiro de 2026) e 2339 (24 de abril) do Baileys, depois a versão 7.0.0-rc10, em 6 de maio de 2026, que envia tctokens e adiciona fetchAccountReachoutTimelock() e um campo reachoutTimeLock em connection.update. O whatsmeow mesclou o ciclo de vida do tctoken em 27 de abril de 2026.
• Os tokens não explicam tudo. Usuários da 7.0.0-rc14 (29 de julho de 2026) ainda relataram o 463 em agosto, e os mantenedores concluíram que é uma restrição da conta, não só um token ausente.

O WAHA transformou isso em endpoints documentados. Desde a versão 2026.8.1 (14 de agosto de 2026), GET /api/sessions/{session}/timelock retorna isActive, timeEnforcementEnds e enforcementType, e um evento session.status informa as mudanças. O WAHA documenta também um segundo limite, baseado em volume: o message capping, que faz os envios falharem com o erro 475 até um ciclo de cota ser reiniciado.

A Evolution API é um caso à parte. A última versão estável (2.3.7, dezembro de 2025) e a branch main fixam o baileys 7.0.0-rc.9 (21 de novembro de 2025), anterior ao envio de tctoken, enquanto a branch develop usa a rc13. Um usuário relatou ter consertado uma sessão nova subindo o Baileys para a rc13 por conta própria.

Quais afirmações ainda não foram confirmadas?

O que fazer quando você vê o 463?

1. Pare de mandar mensagem para novos contatos a partir desse número. Continue respondendo aos chats que já existem.
2. Leia o estado em vez de adivinhar. Use fetchAccountReachoutTimelock() no Baileys, o endpoint timelock do WAHA ou Nova conversa no celular.
3. Não reinicie, não faça logout nem refaça o pareamento. A documentação do WAHA diz que isso não levanta a restrição, e os testes de um contribuidor mostraram que novas tentativas, novos tokens e um fallback de cstoken também não.
4. Confira a sua dependência. Use o Baileys 7.0.0-rc10 ou mais novo e confirme qual versão o seu wrapper fixa.
5. Registre os acks, não só o status HTTP. Alguns wrappers devolvem sucesso enquanto o WhatsApp rejeita a mensagem.
6. Espere o horário de término. A restrição sai sozinha.

Por que projetos em que o usuário escreve primeiro escapam disso?

A restrição mira o primeiro movimento: iniciar conversas com quem nunca escreveu. O próprio conselho do WhatsApp é mandar mensagem para quem entrou em contato primeiro. Um sistema em que o usuário abre o chat, por exemplo a partir de um link wa.me com mensagem pronta, nunca faz esse movimento, então o bloqueio não tem em que agir.

A whasp impõe isso na API. Um número não consegue abrir um chat a frio (409 chat_not_open), e a saúde dele passa a at_risk quando o WhatsApp avisa ou restringe. Os números da whasp rodam o app do WhatsApp num celular, e não uma biblioteca de protocolo, então cuidar dos tokens é trabalho do app, não seu. Isso não torna os banimentos impossíveis: os usuários ainda podem bloquear ou denunciar um número, e quem decide é o WhatsApp. Um número banido é substituído sem custo, mas os chats não migram. Veja por que o WhatsApp bane números.

Para onde ir agora?

Se você roda Baileys, WAHA ou Evolution API, atualize a dependência, registre os acks e acrescente uma regra que bloqueie envios para novos contatos enquanto um timelock estiver ativo. Para comparar as opções, leia o comparativo de APIs não oficiais do WhatsApp. Se um número já foi banido, comece por o que fazer em seguida. Para números novos, veja como aquecer um número de WhatsApp.