Overview
If BroadNet's delivery-report (DLR) webhooks aren't reaching your server, the cause is almost always on the receiving side: no callback URL configured on the account, a URL that isn't publicly reachable over HTTPS, or an endpoint that doesn't return HTTP 200 quickly. The platform POSTs a JSON DLR (MessageId, Status, BatchId and more) to your URL as each message reaches a final state — check the URL, the response, and your firewall first.
No (or wrong) callback URL configured
DLR webhooks only fire if a callback URL is set on your account. If none is configured — or it points at an old or wrong host — nothing is delivered and there is no error to see on your side. Confirm the DLR/webhook URL on the account, and if you can't receive pushes at all, fall back to pulling status on demand (on the legacy HTTP API: GET /websmpp/websmsstatus with the response ID).
- Webhooks require a callback URL set on the account.
- A missing/stale URL means silent non-delivery.
- Verify the configured DLR URL is current.
- Fallback: pull status on demand (legacy HTTP API: /websmpp/websmsstatus).
Endpoint not publicly reachable over HTTPS
The platform POSTs from the public internet, so localhost, a private IP, an untrusted/self-signed TLS certificate, or an IP allow-list that excludes our senders will all stop the callback landing. Expose a public HTTPS endpoint with a valid certificate, and if you allow-list, permit BroadNet's outbound addresses. Test the URL from outside your network before blaming the platform.
- Must be a public HTTPS URL with a valid certificate.
- localhost, private IPs, and self-signed certs won't receive.
- Allow-list BroadNet's senders if you filter inbound traffic.
- Curl the endpoint from outside your network to confirm reachability.
Endpoint not returning 200 quickly
Your endpoint must acknowledge with HTTP 200 promptly. If it returns a 4xx/5xx, times out, or blocks while doing heavy work, the delivery is treated as failed and retried with exponential backoff — which looks like 'missing' or delayed webhooks. Return 200 immediately and process the DLR asynchronously (queue it, then do the work).
- Acknowledge with HTTP 200 fast.
- 5xx/4xx/timeout → retries with backoff (looks like drops).
- Don't do slow work before responding.
- Return 200, then process the DLR off the request path.
It's not a webhook problem — the message isn't final yet
A DLR only fires when a message reaches a terminal state (DELIVRD or UNDELIV). If a message is still queued or scheduled, no report is due yet — that is expected, not a webhook failure. Confirm the message's actual state with a status pull (legacy HTTP API: /websmpp/websmsstatus) before concluding the webhook is broken, and match reports by MessageId or BatchId.
- DLRs fire only at a final state (DELIVRD / UNDELIV).
- Queued or scheduled messages have no DLR yet.
- Check real state with a status pull (legacy HTTP API: /websmpp/websmsstatus) before debugging further.
- Match reports on MessageId or BatchId.