Por que a API do WhatsApp responde 200 com wamid e o PDF ou a mídia não chega?

Porque o 200 com wamid só diz que a Meta aceitou o seu pedido de envio. Quando a mídia vai por link, o que observei é que a Meta busca o arquivo depois, do lado dela, e uma falha nessa busca não volta para a chamada original. O aviso, quando existe, chega pelo webhook de status. Se o seu fluxo só olha o retorno da chamada, ele marca como enviado um PDF que o cliente nunca recebeu.

O que a documentação diz

Conferi as páginas da Meta em 10 de outubro de 2026. Sobre a resposta, a documentação é explícita: ela "só indica que a API aceitou o seu pedido" e não confirma entrega. O status da entrega vem pelos webhooks de mensagens, e o id da resposta é o mesmo que aparece nesses webhooks. O objeto de status pode vir como sent, delivered, read ou failed, e o failed traz um objeto errors com código e detalhe.

Sobre a mídia, a documentação mostra dois caminhos: enviar um link para um arquivo no seu servidor ou enviar o id de um arquivo que você subiu antes para os servidores da Meta. No caso do link, a Cloud API busca o arquivo no seu servidor e guarda uma cópia em cache por 10 minutos, reutilizada se o link for o mesmo. Para forçar uma busca nova, a documentação sugere acrescentar um texto aleatório na query string.

A página de mídia diz que IDs gerados por upload expiram em 30 dias e que documentos aceitam até 100 MB. Não vi documentado, nas páginas que li, um tempo máximo que a Meta espera pela resposta do seu servidor ao buscar o link. Por isso o que segue sobre lentidão vem do que medi, não de uma regra publicada.

O que vi em produção

Um cliente tinha um fluxo que mandava um PDF de apresentação de 29 MB por link para quem pedia o material. Passou a reclamar que o arquivo não chegava, embora cada envio retornasse 200 com wamid e o alarme de erro do fluxo nunca tivesse disparado.

O link apontava para um endereço do próprio sistema de automação, que baixava o PDF de outro lugar a cada pedido só para ajustar o tipo do arquivo. Medi 10 a 19 segundos até o primeiro byte e cerca de 1,5 MB por segundo de vazão, o que dá entre 16 e 27 segundos para o arquivo inteiro. Em uma hospedagem estática do mesmo arquivo, a resposta começava em 0,08 a 0,24 segundo, a 10,9 MB por segundo.

O sinal que denunciou o problema foi o log do servidor de origem: em vez de um acesso por envio, havia seis, com intervalo crescente entre eles. Um download bem-sucedido acontece uma vez. Várias tentativas seguidas parecem nova tentativa da Meta, e foi assim que li. Isso é leitura minha dos acessos, a documentação que li não descreve esse comportamento.

Troquei só a URL, para a hospedagem estática, e fiz o teste de controle: mesmo número, mesma janela de 24 horas, 76 segundos de diferença, mesmo arquivo. Pela URL nova, o PDF chegou e abriu. Pela antiga, o PDF não chegou, e o log da origem mostrou as várias buscas descritas acima.

Por que acontece

O fluxo tem, pelo que observei, duas etapas. A primeira é a chamada de envio, que a Meta responde na hora com wamid. A segunda é a Meta buscar o arquivo no seu link, e essa etapa não volta para a primeira. A documentação só confirma que a resposta apenas indica aceite e que falhas aparecem no webhook com status failed. Que a lentidão da URL seja a causa é a conclusão do meu teste de controle, não uma regra publicada.

Há uma segunda causa que dá o mesmo sintoma, e confundi as duas num teste. Mensagem livre, sem ser template, só chega a quem falou com o número nas últimas 24 horas, e a API também devolve 200 com wamid fora dessa janela. A documentação de erros descreve o 131047 para quem passou de 24 horas desde a última resposta. Para separar as causas, mande um texto simples ao mesmo número: se o texto também não chega, o problema é a janela, e não a mídia.

O que conferir

1. Ouvir o webhook de status e alertar em failed, com o código do erro. Sem isso, você só descobre pelo cliente.
2. Medir o tempo de resposta da URL do arquivo: tempo até o primeiro byte e vazão. Servir arquivo grande de dentro de uma automação é a escolha errada. Use armazenamento de objetos ou uma hospedagem estática.
3. Conferir o content-type da resposta. No meu caso, o mesmo PDF servido como application/octet-stream chegava como um arquivo .bin. O tipo vem do cabeçalho do servidor, e o nome que você informa na chamada não resolve.
4. Escolher entre link e ID. Link público estável evita a expiração, e o ID de upload expira em 30 dias, o que quebra o fluxo de tempos em tempos se ninguém renovar.
5. Descartar a janela de 24 horas antes de culpar a mídia, com o teste do texto simples.
6. Olhar o log do servidor de origem. Acessos repetidos ao mesmo arquivo por um único envio indicam tentativas de download que não deram certo.

Para montar esse tipo de fluxo com alertas que mostram a falha real, veja atendimento no WhatsApp com IA.