TL;DR: Agosto de 2026 é o panorama do mês, não um changelog com datas. Ative outgoing_calls_enabled e faça POST /calls/outgoing para um toque padrão de 5 segundos sem áudio. HTTP 200 significa que o WhatsApp aceitou a oferta. Catálogos, grupos, consultas LID e rotação de proxy Partner após um ban mostram que o gateway ainda acompanha o WhatsApp.
Em agosto de 2026, a Whapi.Cloud acompanhou o WhatsApp. O mês entrega um toque de chamada de atenção de saída sem áudio, e os demais patches seguem as mudanças da plataforma para que donos de negócio e integradores tratem a API como um canal de negócio mantido.
Já vimos operadores de agência com uma dezena de números de clientes em Node.js ou n8n tratarem HTTP 200 como conversa encerrada. O toque só interrompe; o chat não lido ainda precisa do acompanhamento. Este guia não entra em setup método a método nem em schemas de webhook campo a campo.
O que uma chamada WhatsApp de saída sem áudio faz de verdade?
A chamada de atenção é um toque sem áudio e sem VoIP. Você define uma janela de 0 a 30 segundos, padrão 5, e um 200 só significa que o WhatsApp aceitou a oferta.
HTTP 200 significa que o WhatsApp aceitou a oferta, não que o destinatário atendeu. Nenhum áudio é transmitido, e a chamada termina quando a janela de duração fecha. Essa é a capacidade nova do mês, documentada em iniciar uma chamada WhatsApp de saída.
Bibliotecas da comunidade já observavam chamadas de entrada há anos e ainda precisavam de WebRTC para um toque de saída. A Whapi.Cloud agora expõe o mesmo trabalho via HTTP: faz o aparelho vibrar e continua no chat.
Duração 0 termina imediatamente depois que a oferta é reconhecida. A flag do canal é outgoing_calls_enabled em Channel Settings; ao ligá-la, o canal reinicia. Leitura complementar: GET /calls/{CallID}, que retorna result, horário de atendimento e status já no canal conectado. Não pede histórico de chamadas aos servidores do WhatsApp.
O formato da request de POST /calls/outgoing está abaixo. Use o call_id retornado com esse GET para detalhes locais do canal.
// HTTP 200 here means WhatsApp accepted the offer.
// Treat it as answered and you skip the unread-chat follow-up while the ring is already gone.
const res = await fetch('https://gate.whapi.cloud/calls/outgoing', {
method: 'POST',
headers: {
Authorization: `Bearer ${process.env.WHAPI_TOKEN}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({ to: '1234567890', duration: 5 })
});
const data = await res.json();
// data.status is initiated; pair call_id with GET /calls/{CallID} for channel-local details
Os eventos de chamada agora incluem answered_at, finalized e status. O mapa do payload está em webhooks de chamadas recebidas.
Toque de sinalização para chats não lidos — Cloud Calling cobra pulsos de voz
Use Cloud Calling quando você já tem permissão para um pulso de voz de verdade. Use o toque do gateway quando o chat continua não lido e você precisa que o aparelho vibre, depois siga no WhatsApp.
Sessenta e dois por cento das chamadas de negócio recebidas ficam sem resposta (Aira, reportado via SocialVik). O correio de voz recupera cerca de uma em cem. Toque primeiro, depois siga no WhatsApp quando o chat continua não lido. Clínicas já transformam voz de entrada perdida em um thread de agendamento.
Na API oficial do WhatsApp Business, chamadas iniciadas pelo negócio exigem permissão explícita do usuário, e quatro chamadas sem resposta consecutivas revogam essa permissão automaticamente. Na Whapi.Cloud, POST /calls/outgoing é um toque de sinalização sem mídia VoIP, porque o gateway roda em sockets de sessão web e não vende telefonia IP. Usar Cloud Calling como um alerta barato em chat não lido esbarra nessa escada de permissão e, depois de quatro perdas, na revogação.
| Decisão | Chamada de atenção do gateway | Meta Cloud Calling (BIC) |
|---|---|---|
| O que o destinatário recebe | Um toque curto; a chamada termina depois da janela de duração | Uma sessão de voz WebRTC ao vivo |
| Modelo de permissão | Flag do canal outgoing_calls_enabled |
Permissão prévia do usuário; quatro chamadas sem resposta revogam |
| Sinal de sucesso | HTTP 200 = WhatsApp aceitou a oferta | Um pulso de voz de fato conectado no produto Cloud Calling |
| Para que serve | Chamar atenção em um thread WhatsApp não lido | Manter uma conversa telefônica de verdade |
Agências já associam abordagem proativa a contatos novos com taxas de ban de 15-30% contra menos de 2% em bots só de entrada. Mantenha o novo toque de saída como acompanhamento de um thread não lido. Quem reage é a detecção de spam no servidor do WhatsApp; os planos de produção da Whapi.Cloud não limitam a frequência de chamadas.
Manutenção de agosto: catálogo, pedidos, grupos, Comunidades, enquetes e labels
Trate os patches de loja, grupo e identidade como uma só prova de atualização: a superfície HTTP ainda acompanha o WhatsApp.
Webhooks de entrada agora chegam com identidades @lid; as consultas LID-para-telefone restauram a chave de roteamento do CRM. Projetos que pulam a consulta começam a gravar linhas duplicadas no CRM na semana em que o WhatsApp troca a identidade do webhook. Os envios falham quando a tabela de chats não tem mapeamento LID depois dessa migração. A leitura que explica o conserto é como o LID do WhatsApp volta para um número de telefone.
Operação da loja: catálogos, produtos e pedidos
Os endpoints de listagem de catálogo agora falham se a instância não estiver autorizada, e o WhatsApp aplica rate-limit no GraphQL de catálogo. A manutenção de agosto devolveu create, update e delete sob uma sessão ao vivo, inclusive catálogos de contato, envio de mensagem de produto e recuperação de pedido por OrderID ou order_token. Pedidos LID que travam retentam pelo mapeamento de telefone. O que quebrou foi um scrape de catálogo público sem canal conectado.
Grupos, Comunidades e enquetes
Atualização de ícone de grupo, votação simultânea em enquetes e adição de participantes depois que uma Comunidade é criada eram os pontos mais instáveis. A recuperação de Comunidade após o start do canal falhava com a sessão no ar e a lista de Comunidades ainda vazia. WhatsApp 479 em um envio de grupo agora retenta.
A criação parcial de grupo retorna unprocessed_participants em vez de fingir que toda adição deu certo. Sync de histórico de chat, exclusão de status e font_type de status de texto entram no mesmo saco: o gateway acompanhou o que o WhatsApp mudou.
Consultas LID, labels e cota de phone-check
Identificadores LID substituíram JIDs de telefone em uma fatia crescente dos eventos de entrada. As consultas restauram as chaves de roteamento do CRM. GET /contacts/ids/{ContactLID} (getIdByLid) é a consulta que restaura a chave de telefone do CRM. LID-para-telefone retorna 404 quando não há mapeamento e 502 quando o serviço de consulta está indisponível. Esses dois códigos separam "essa pessoa é desconhecida" de "o caminho de consulta caiu."
O sync de labels do telefone e a gestão de labels em chats LID chegaram na mesma leva. Consultas LID-para-telefone em Trial e Sandbox contam no limite de phone-check, então um loop de mapeamento num canal de teste queima a mesma cota de um existence check de produção. A validação de mensagem citada agora retorna 400 em vez de 500. A verificação de número é cacheada e feita em lote.
Troque o proxy antes de autorizar o número substituto
Depois de um ban, troque o proxy antes de autorizar o número substituto. O mesmo IP comprometido é o que faz SIMs substitutos levarem ban em sequência.
Na prática, times que reconectam um SIM novo no mesmo proxy veem o substituto cair na mesma semana. Uma agência com quem resolvemos esse caso trocou um SIM banido, manteve o proxy antigo e perdeu o número novo antes de terminar o warmup. Troque o proxy antes de autorizar o número substituto. A Partner API agora expõe o passo que faltava: alterar o proxy do canal na frota e, só então, autorizar o próximo número. As opções de proxy regional e padrão estão documentadas em proxies padrão e regionais.
Warmup, picos de volume e copy em massa idêntica continuam em como evitar um ban no WhatsApp em 2026. A história deste mês é a ordem de reconexão depois de um ban. Proxies únicos e provedores regionais já isolam canais; a rotação via Partner API é a alavanca quando o número já se foi. Mais de 3.000 clientes ativos rodam esse stack em produção todos os dias.
Versões antigas do WhatsApp disparam handshake 405 até o gateway acompanhar
Versões antigas do WhatsApp disparam handshake 405 até o gateway acompanhar o protocolo atual. Essa é a história silenciosa de confiabilidade do mês.
Instalações self-hosted ficam presas a uma versão de protocolo, o WhatsApp exige um handshake mais novo, e os sockets falham com 405 mesmo quando o cliente anuncia uma versão web atual. A Whapi.Cloud absorve essas mudanças de protocolo no gateway, então os caminhos HTTP do cliente ficam estáveis enquanto o gateway acompanha o WhatsApp. Se um canal ainda retorna 405 depois de uma mudança de protocolo da plataforma, use o widget de chat em whapi.cloud.
O que operadores devem levar do panorama de agosto de 2026?
Em agosto de 2026, a Whapi.Cloud entregou um toque de chamada de atenção e corrigiu o restante para que operadores confiem num canal WhatsApp mantido.
O toque de saída sem áudio é o destaque do mês. Catálogo, grupos, consultas LID, labels e rotação de proxy Partner são a manutenção que mantém o canal atualizado. As release notes datadas ficam no changelog do produto. Um 200 ainda só registra que o WhatsApp aceitou a oferta.
A Whapi.Cloud conecta por sockets de sessão web, o mesmo caminho que o WhatsApp Web usa. Nessa categoria de API não oficial, toques de sinalização chamam atenção; Cloud Calling cobra pulsos de voz WebRTC.
