Editar, apagar e encaminhar mensagem no WhatsApp API

Editar, apagar e encaminhar mensagens já enviadas pela API do WhatsApp são três ações simples — um PUT, um DELETE e um POST, todos referenciando o identificador da mensagem original. Servem para corrigir erro sem poluir a conversa, remover algo enviado errado a tempo e reaproveitar conteúdo entre contatos sem digitar de novo.

As três ações e quando usar cada uma

Todas dependem de um único dado: o identificador da mensagem (MSG_ID), que sua aplicação recebe na resposta de quando envia a mensagem original ou no evento de webhook.

Editar mensagem

curl -X PUT https://us.api-wa.me/{KEY}/message/{MSG_ID} \
  -H "Content-Type: application/json" \
  -d '{"text": "Seu pedido #4821 chega até as 19h (horário corrigido)."}'

O caso de uso mais direto é a correção de dado dinâmico: sua automação mandou "chega às 18h" com base numa estimativa que depois mudou para 19h. Em vez de mandar uma segunda mensagem — que deixa duas informações conflitantes na tela do cliente — a edição substitui o texto e marca a mensagem como editada, igual a quando um humano corrige pelo app.

Isso é diferente de mandar uma mensagem de correção separada, que é o que a maioria das integrações faz hoje por não conhecer esse endpoint — e que deixa a conversa com informação contraditória visível para sempre.

Apagar mensagem

curl -X DELETE https://us.api-wa.me/{KEY}/message/{MSG_ID}

O ponto de atenção é o tempo. Apagar-para-todos segue a mesma janela do app: passado esse prazo, a chamada só remove a mensagem da sua própria instância, não da tela de quem recebeu. Isso significa que uma automação de correção precisa reagir rápido — detectar o erro e chamar o endpoint em segundos ou poucos minutos, não em uma rotina que roda de hora em hora.

Um padrão comum: sua aplicação envia uma confirmação de pedido, e uma validação assíncrona logo depois descobre que o pedido tinha erro de estoque. Se essa validação é rápida o bastante, apagar a mensagem e mandar a correta evita o cliente ver uma confirmação que não é mais verdadeira.

Encaminhar mensagem

curl -X POST https://us.api-wa.me/{KEY}/message/{MSG_ID}/forwarding \
  -H "Content-Type: application/json" \
  -d '{"to": "5511888888888"}'

Encaminhar é diferente de responder: a resposta cria uma mensagem nova citando a original, enquanto o encaminhamento reenvia o mesmo conteúdo para outro destinatário, sem duplicar o texto na sua aplicação. Serve para repassar um aviso, um documento ou uma imagem de um contato — ou de um grupo — para outro, sem baixar o arquivo e subir de novo.

Combinado com automatizar grupos de WhatsApp pela API, dá para montar um fluxo de replicar aviso: uma mensagem publicada num grupo principal é encaminhada automaticamente para grupos satélite, sem reescrever o conteúdo em cada um.

Editar vs. apagar e reenviar: qual escolher

As duas abordagens resolvem "eu mandei a informação errada", mas com efeitos diferentes na conversa:

Editar preserva o contexto da conversa — a resposta do cliente que já veio em cima da mensagem original continua fazendo sentido. Apagar e reenviar quebra esse contexto: se o cliente já respondeu algo baseado na mensagem errada, a resposta dele fica "solta", sem a mensagem que a originou. Por isso, para erro pequeno, editar é quase sempre a opção que gera menos confusão.

Registrando o identificador da mensagem corretamente

Todas as três ações dependem do MSG_ID da mensagem original, e o erro mais comum de quem implementa isso pela primeira vez é não guardar esse identificador no momento certo. Duas fontes confiáveis:

• Resposta síncrona do envio — quando sua aplicação chama o endpoint de envio, a resposta já traz o identificador da mensagem criada. Salvar esse valor junto do registro do pedido, do agendamento ou do que gerou o envio é o que permite editar ou apagar depois.
• Evento de webhook — para mensagens recebidas do cliente (não enviadas por você), o identificador chega no payload do webhook, e é esse valor que se usa para, por exemplo, encaminhar a mensagem de um cliente para outro atendente ou canal.

Sem salvar esse identificador no momento do envio, a única forma de "corrigir" um erro depois é mandar uma mensagem nova — perdendo a vantagem de editar ou apagar. Vale tratar o MSG_ID como parte obrigatória do registro de qualquer envio automatizado, não como um dado descartável.

Encaminhar em cadeia: cuidado com o eco

Encaminhar mensagem entre grupos ou contatos é útil, mas tem uma armadilha comum em automação: encaminhar em loop. Se o grupo A encaminha automaticamente para o grupo B, e o grupo B está configurado para encaminhar de volta para o A, a mesma mensagem circula indefinidamente.

Duas proteções simples evitam isso:

• Marcar a mensagem encaminhada com um identificador de origem no seu próprio sistema, e checar essa marca antes de encaminhar de novo;
• Definir direção única entre grupos ou contatos — A encaminha para B nunca deveria coexistir com B encaminhando de volta para A no mesmo fluxo automatizado.

Onde essas ações entram no fluxo de erro

O ponto comum das três ações é corrigir sem sujar a conversa. Numa automação de disparo com fila, rate limit e retry, erros acontecem — dado errado no template, destinatário trocado, mensagem duplicada por retry mal tratado. Ter editar e apagar como parte do tratamento de erro, e não só o log da falha, é o que separa uma automação que se corrige sozinha de uma que deixa rastro de erro na conversa do cliente.

Vale registrar cada edição e exclusão no mesmo lugar que você já guarda os eventos de entrega — os mesmos dados que alimentam métricas de campanha no WhatsApp — para saber quantas correções sua automação está fazendo e por quê. Taxa de edição alta é sinal de que o dado de origem (estoque, prazo, preço) está chegando errado antes mesmo de virar mensagem.

Erros comuns ao implementar as três ações

Tentar editar uma mensagem de mídia como se fosse texto. O endpoint de edição substitui texto; imagem, áudio e documento já enviados não têm o conteúdo trocado da mesma forma — para esses casos, o caminho é apagar e reenviar com o arquivo correto.

Não tratar o erro de "janela expirada". Chamar apagar ou editar depois do prazo permitido retorna erro, e uma automação que não trata essa resposta some sem explicação, sem confirmar se a correção realmente saiu. Trate esse retorno como um caminho esperado, não uma exceção rara.

Encaminhar em massa sem espaçar. Encaminhar a mesma mensagem para dezenas de contatos em sequência rápida tem o mesmo perfil de risco de um disparo em massa mal feito — vale aplicar o mesmo cuidado de fila, rate limit e retry em vez de rodar um laço direto contra a API.

Esquecer de atualizar o próprio registro depois de editar ou apagar. Se sua aplicação guarda uma cópia do texto enviado para exibir num painel interno, por exemplo, essa cópia precisa ser atualizada junto da chamada à API — senão o painel mostra uma mensagem que já não é mais o que o cliente vê.

Quando não vale a pena automatizar a correção

Nem todo erro justifica construir uma automação de correção. Se o erro é raro — acontece uma vez a cada duas mil mensagens — corrigir manualmente pelo app, quando notado, é mais barato do que manter um sistema de detecção e correção automática rodando o tempo todo.

Vale automatizar quando o erro é sistemático: nasce de um dado de origem que muda depois do envio (previsão de entrega, estoque, preço) e por isso vai continuar acontecendo em escala. Nesses casos, o ganho de corrigir automaticamente supera o custo de manter a automação — porque o problema não vai parar de aparecer sozinho.

Conclusão

Editar, apagar e encaminhar mensagem pela API resolvem o problema depois que a mensagem já saiu — corrigir dado, remover envio errado, reaproveitar conteúdo. O detalhe que decide se funciona é o tempo: editar e apagar valem a pena quando a automação reage rápido ao erro, não quando descobre horas depois que já não há mais o que fazer.