WhatsApp: mensagem enviada, mas não entregue?
“Enviada” não confirma que a mensagem chegou. Consulte o status no provedor, confira se eventos ou callbacks estão ativos e use o código de erro para investigar a tentativa.
Quando uma mensagem aparece como enviada, isso ainda não confirma que chegou ao destinatário. A documentação da AWS distingue estados como accepted (aceita para processamento), sent (enviada, mas ainda em trânsito), delivered (entregue) e read (lida, quando há recibo de leitura) (status de mensagens do WhatsApp na AWS).
Na integração da Twilio, o envio de atualizações depende de configurar uma URL de callback de status; a documentação explica que o callback pode trazer o identificador da mensagem, o status e um código de erro quando houver (guia da Plataforma WhatsApp com Twilio). O diagnóstico começa por consultar o evento e sua definição no provedor usado, não por reenviar às cegas.
O que os status dizem
Os rótulos descrevem etapas diferentes. Na tabela de status da AWS, accepted significa que o WhatsApp aceitou a mensagem para processamento; sent indica que ela foi enviada, mas ainda está em trânsito; delivered significa que foi entregue ao cliente. Já read indica leitura e só é enviado quando o cliente mantém recibos de leitura ativados. Portanto, não use “enviado” e “lido” como sinônimos de “entregue”.
A mesma documentação também lista failed, para uma mensagem que falhou ao enviar, e warning, quando ela contém um item indisponível ou inexistente. Esses estados dão uma pista do que investigar, mas não substituem o detalhe do evento nem a explicação do fornecedor. Os nomes exatos e a forma de receber atualizações dependem da integração consultada.
| Status documentado pela AWS | Leitura prática | |---|---| | accepted | Aceita pelo WhatsApp para processamento | | sent | Enviada, ainda em trânsito | | delivered | Entregue ao cliente | | read | Lida; depende dos recibos de leitura | | failed | Falha no envio | | warning | Há um item indisponível ou inexistente |
A pergunta “não entregou?” precisa ser respondida com o status mais recente associado à mensagem, e não apenas com a tela em que o atendente clicou em enviar. Em uma caixa compartilhada, registre qual provedor ou integração fez o envio e qual identificador aparece no detalhe. Se os registros de duas ferramentas forem misturados, uma consulta pode acabar sendo feita no lugar errado.
Onde acompanhar a atualização
Na AWS End User Messaging Social, a documentação de status diz que é necessário ativar o registro de eventos para receber notificações. Se o log estiver desabilitado ou apontando para um destino que ninguém acompanha, a equipe pode não ver a sequência de atualizações. A conferência deve começar pela configuração de eventos, pela janela de tempo consultada e pelo identificador da mensagem.
A documentação da Twilio documenta outra opção para mensagens de saída: configurar uma Status Callback URL no Console ou incluir o parâmetro StatusCallback ao enviar a mensagem. A cada mudança de status, a Twilio envia uma solicitação à URL; a documentação informa que ela inclui o SID da mensagem, o status e um error_code associado, se houver. Isso permite relacionar a falha a um envio específico sem depender apenas de uma captura de tela.
Esses mecanismos não são intercambiáveis. O registro de eventos descrito pela AWS pertence à configuração AWS; o callback citado na documentação da Twilio pertence à integração Twilio. Se uma operação usa outro BSP ou conexão direta, consulte o painel e a referência desse ambiente. O artigo https://atendefacil.blog/blog/whatsapp-business-x-api-oficial ajuda a separar o aplicativo de uma integração por API; a forma de acompanhar o status depende de qual caminho foi contratado.
Diagnóstico em seis etapas
- Localize a mensagem certa. Use o identificador registrado pelo sistema ou pelo provedor e confira o horário. Se houver diversos envios para o mesmo contato, associe cada tentativa ao seu próprio ID.
- Confirme a conexão que enviou. Veja se a mensagem saiu pela integração AWS, Twilio ou outro fornecedor. Não procure um evento de uma ferramenta em outra.
- Verifique se a observabilidade está ativa. Na AWS, confira se o registro de eventos está habilitado. Na Twilio, veja se o Status Callback foi configurado para esse envio ou serviço.
- Leia o status e a transição. Diferencie aceite, envio em trânsito, entrega, leitura e falha conforme a definição publicada pelo provedor. Se só há um estado inicial, não conclua que ele equivale ao estado final.
- Abra o código de erro, quando existir. A documentação da Twilio indica que o callback pode incluir error_code. Consulte a referência do provedor para entender o evento antes de alterar configuração ou tentar outro envio.
- Decida com base no resultado observado. Se o status final aponta falha, investigue a causa indicada. Se aparece como enviado ou aceito, mas não como entregue, procure a atualização seguinte e verifique a configuração de eventos antes de duplicar a mensagem.
Essa sequência ajuda a separar três situações que parecem iguais para quem está no atendimento: a ferramenta não registrou a resposta, o provedor ainda está processando o envio ou o provedor registrou uma falha. O texto do erro e o status associado à tentativa são mais úteis para escolher o próximo passo do que repetir a mesma ação sem saber o resultado anterior.
Checklist de teste antes de ativar o fluxo
Antes de depender de um fluxo em uma rotina de atendimento, registre como cada cenário será verificado. Faça os testes na configuração aprovada pela empresa e anote o resultado sem incluir conteúdo sensível desnecessário.
| Cenário | Evidência que deve ser localizada | Decisão | |---|---|---| | Envio aceito | ID da mensagem e primeiro evento observado | Acompanhar as transições seguintes | | Envio entregue | Evento com status delivered no provedor | Encerrar a conferência de entrega | | Falha de envio | status failed e código ou descrição disponível | Corrigir a causa antes de repetir | | Sem atualização visível | Registro de eventos ou callback configurado? | Verificar observabilidade antes de concluir | | Status read ausente | Há recibo de leitura disponível? | Não usar ausência de leitura como prova de falha |
Na AWS, a própria documentação condiciona as notificações à ativação do log de eventos; por isso, “não encontrei o callback” não é o mesmo que “a mensagem falhou”. Na Twilio, confira a URL de callback e os campos recebidos. O artigo https://atendefacil.blog/blog/como-automatizar-atendimento-whatsapp pode ajudar a situar esse monitoramento dentro do fluxo completo: uma automação de atendimento precisa prever como a equipe consulta o resultado quando a resposta não chega como esperado.
Como interpretar os casos mais comuns
Aparece accepted, mas não há outro status. Trate o registro como aceito para processamento. Consulte os eventos seguintes e confirme se a integração entrega atualizações ao destino configurado. A definição da AWS não diz que accepted equivale a delivered.
Aparece sent. A AWS descreve esse status como mensagem enviada que ainda está em trânsito. A equipe deve acompanhar o próximo evento e verificar a fonte de status usada, em vez de apresentar a mensagem como confirmada ao destinatário.
Aparece delivered, mas o cliente diz que não viu. O status da AWS significa que a mensagem foi entregue ao cliente. Isso não é o mesmo que read; o recibo de leitura pode depender da configuração do destinatário. Confira também se a conversa e o contato vistos pela equipe correspondem ao envio.
Aparece failed ou existe error_code. Guarde o código, a descrição exibida e o ID de mensagem. Consulte a documentação da integração antes de trocar número, credencial ou fluxo. Uma intervenção baseada em um código lido fora do contexto pode corrigir o componente errado.
Para lidar com dúvidas frequentes sem automatizar tudo, https://atendefacil.blog/blog/respostas-rapidas-whatsapp-business-exemplos mostra como organizar respostas prontas; já https://atendefacil.blog/blog/organizar-pedidos-whatsapp trata do acompanhamento da conversa e dos próximos passos. O monitoramento de status é uma camada técnica separada: ele informa o que o provedor registrou para o envio e orienta a investigação.
Como reduzir dúvidas na próxima ocorrência
Defina um padrão curto para registrar cada incidente: integração utilizada, identificador da mensagem, status visto, data e hora, código de erro se houver, e ação tomada. Assim, outra pessoa consegue recuperar a tentativa sem reconstituir a história inteira no chat da equipe. Para compartilhar evidências, prefira os campos técnicos necessários e evite copiar a conversa completa quando ela não for relevante.
Também combine quem verifica a configuração de eventos e quem decide se um envio pode ser repetido. Essa divisão evita que várias pessoas reenviem a mesma mensagem enquanto uma atualização ainda está pendente. A equipe não precisa transformar cada status em uma auditoria extensa; basta que o procedimento permita diferenciar uma falha confirmada de uma atualização ainda incompleta.
Mantenha um registro simples dos testes que foram feitos após qualquer ajuste: qual cenário foi simulado, qual status apareceu, qual callback ou evento foi recebido e em qual painel a equipe encontrou a evidência. Se o comportamento mudar após uma alteração do fornecedor, valide novamente na documentação atual. Uma lista pequena e atualizada torna o próximo diagnóstico mais rápido e consistente.
Fontes
Perguntas frequentes
“Enviado” quer dizer que o cliente recebeu?
Não necessariamente. A AWS diferencia sent, que ainda está em trânsito, de delivered, que indica entrega. Consulte o status mais recente no provedor usado.
“Entregue” significa que a pessoa leu?
Não. Na documentação da AWS, read é um status separado e depende de recibos de leitura ativados pelo cliente.
Onde vejo o motivo de uma falha na Twilio?
Confira o callback de status e o error_code associado, quando houver. A documentação recomenda relacionar a atualização ao SID da mensagem e consultar a referência de erro correspondente.
Por que não aparece atualização de status na AWS?
A AWS informa que é preciso habilitar o registro de eventos para receber as notificações. Confira essa configuração e o destino de eventos usado pela integração.
Este conteúdo pode conter links de afiliado: se você comprar por eles, o blog recebe uma comissão, sem custo extra para você.
Fontes para conferir por conta própria
Referências oficiais e confiáveis sobre o tema deste blog. Confira sempre a versão mais recente antes de decidir.
