Overview
Se os webhooks de relatório de entrega (DLR) da BroadNet não estiverem a chegar ao seu servidor, a causa quase sempre está no lado do recetor: nenhuma URL de retorno configurada na conta, uma URL que não é acessível publicamente via HTTPS ou um endpoint que não devolve HTTP 200 rapidamente. A plataforma envia um DLR JSON (MessageId, Status, BatchId e mais) para a sua URL assim que cada mensagem atinge um estado final — verifique a URL, a resposta e o seu firewall primeiro.
URL de retorno de chamada não configurada (ou configurada incorretamente).
Os webhooks do DLR só são acionados se um URL de retorno de chamada estiver configurado na sua conta. Se nenhum estiver configurado — ou se apontar para um host antigo ou incorreto — nada será entregue e não haverá nenhum erro para você visualizar. Confirme o URL do DLR/webhook na conta e, se não conseguir receber notificações push, consulte o status a pedido (pela API HTTP legada: GET /websmpp/websmsstatus com o ID de resposta).
- Os webhooks exigem que um URL de retorno de chamada seja configurado na conta.
- Uma URL ausente ou desatualizada significa que a entrega não será efetuada sem aviso prévio.
- Verifique se o URL do DLR configurado está atualizado.
- Alternativa: consultar o status a pedido (API HTTP legada: /websmpp/websmsstatus).
O endpoint não está acessível publicamente via HTTPS.
A plataforma envia requisições POST da internet pública, portanto, localhost, um IP privado, um certificado TLS não confiável/autoassinado ou uma lista de permissões de IP que exclua os nossos remetentes impedirão a receção da requisição. Exponha um endpoint HTTPS público com um certificado válido e, se você usar uma lista de permissões, permita os endereços de saída da BroadNet. Teste a URL de fora da sua rede antes de culpar a plataforma.
- Deve ser um URL HTTPS público com um certificado válido.
- Localhost, IPs privados e certificados autoassinados não serão aceitos.
- Adicione os remetentes da BroadNet à lista de permissões se você filtrar o tráfego de entrada.
- Execute um curl no endpoint a partir de fora da sua rede para confirmar a acessibilidade.
O endpoint não está a devolver 200 rapidamente.
O seu endpoint deve responder prontamente com um HTTP 200. Se devolver um código 4xx/5xx, expirar o tempo limite ou ficar bloqueado durante uma operação pesada, a entrega será tratada como falha e repetida com um backoff exponencial — o que se assemelha a webhooks "ausentes" ou atrasados. Devolva 200 imediatamente e processe o DLR de forma assíncrona (enfileire-o e, em seguida, execute a operação).
- Confirme rapidamente com HTTP 200.
- 5xx/4xx/timeout → novas tentativas com recuo (parece que houve perda de pacotes).
- Não faça trabalho lento antes de responder.
- Devolva 200 e, em seguida, processe o DLR fora do caminho da solicitação.
Não é um problema de webhook — a mensagem ainda não é final.
Um DLR (Relatório de Entrega de Mensagem) só é acionado quando uma mensagem atinge um estado final (ENTREGADA ou NÃO ENTREGUE). Se uma mensagem ainda estiver na fila ou agendada, nenhum relatório é devido ainda — isso é esperado e não indica uma falha do webhook. Confirme o estado real da mensagem com uma consulta de status (API HTTP legada: /websmpp/websmsstatus) antes de concluir que o webhook está com defeito e compare os relatórios por MessageId ou BatchId.
- Os DLRs disparam apenas num estado final (ENTREGADO / DESENTREGADO).
- As mensagens enfileiradas ou agendadas ainda não possuem DLR.
- Verifique o estado real com uma consulta de status (API HTTP legada: /websmpp/websmsstatus) antes de prosseguir com a depuração.
- A correspondência de relatórios é feita com base no MessageId ou BatchId.