Webhooks or inbound replies are not arriving
Missing inbound traffic — replies, delivery reports, or status callbacks that never reach your system — is nearly always caused by registration, endpoint health, or TLS, in that order. Work through the diagnostic sequence below before assuming the platform failed to send the event.
Diagnostic sequence
- Confirm registration. Open Settings → Channels and check the inbound URL registered against the channel. A URL that is correct but points at the wrong environment (staging instead of production) is the single most common cause of "nothing arrives."
- Confirm endpoint health. Your endpoint must return a 2xx status quickly. A response that arrives after the provider's timeout window counts as a failure and triggers a retry, which can present as intermittent rather than total silence.
- Confirm TLS and reachability. The host must be publicly reachable with a valid certificate from a recognised certificate authority. Self-signed certificates, expired certificates, and hosts behind authentication walls are rejected before your handler ever runs.
- Inspect the retry log. The channel log shows every delivery attempt and the response code your endpoint returned. This tells you whether the provider is trying and failing (endpoint or TLS issue) or not attempting at all (registration issue).
- Verify signature handling. If your handler verifies a signature header, confirm you hash the raw, unparsed request body. Frameworks that automatically parse JSON before your handler runs often re-serialise it, changing whitespace and key order and breaking the signature comparison even though the payload content is unchanged.
- Escalate with specifics. If all five checks are clean, escalate with the exact time window and, if visible, a request or delivery ID from the retry log.
Cause and fix
| Cause | Symptom in retry log | Fix |
|---|---|---|
| Wrong or stale URL registered | No attempts logged at all | Update the URL in Settings → Channels |
| Slow endpoint response | Attempts logged, timeout response code | Acknowledge immediately, process asynchronously |
| Invalid or expired TLS certificate | Attempts logged, connection error | Renew certificate from a public CA |
| Endpoint behind auth wall or firewall | Attempts logged, 401/403/timeout | Allow the provider's IP ranges or remove the auth requirement on this route |
| Signature check failing on valid payloads | Attempts logged, 401 from your own handler | Hash the raw body before any parsing middleware runs |
| Duplicate records from retries | No missing data, but duplicated rows | Deduplicate on the provider's message ID |
Design for retries, not exactly-once delivery
Webhook deliveries are retried on any ambiguous failure, so a well-behaved integration is idempotent: it uses the provider's message ID to detect and skip a delivery it has already processed, rather than assuming each webhook call represents a new event. This also protects you if a retry is delivered out of order relative to your own processing time.
Escalation path by connection status
Every client owns their own Infobip account, so provider-side tracing is always against the client's own Infobip keys. Where the webhook trace needs provider-side investigation, the correct destination depends on whether the instance is connected to Arino Core.
| Connection status | First-line diagnostics | Escalate to |
|---|---|---|
| Connected ($50/month Arino Core connection) | Arino support, using the console and logs | Arino support, tracing against your Infobip keys |
| Unconnected | Your team | Infobip and/or Meta support directly — Arino does not hold your keys and cannot trace provider-side delivery attempts |
When escalating, provide the registered webhook URL, the exact time window of the missing events, and any request IDs visible in your own server logs. Clients on an unconnected instance should have the same information ready when contacting Infobip or Meta support directly, since neither support channel will investigate without a concrete time window.
Steps at a glance
- Confirm the webhook is registeredCheck the inbound URL registered on the channel in Settings → Channels and confirm it matches the endpoint you are monitoring.
- Check endpoint healthYour endpoint must return a 2xx response quickly; slow responses are treated as failures and retried, which can look like intermittent silence.
- Check TLS and reachabilityA valid, non-expired certificate and a publicly reachable host are required. Self-signed certificates, internal-only hostnames, and expired certs are all rejected silently by most providers.
- Inspect the retry logReview recent delivery attempts and response codes in the channel log to see whether the provider is trying and failing, or not attempting delivery at all.
- Verify signature handlingIf you verify signatures, confirm you hash the raw request body, not a re-serialised copy — re-serialising JSON changes byte order and breaks the comparison even when the payload looks identical.
- Escalate with a request ID and time windowIf registration, health, TLS, and signature checks are all clean, escalate with a specific time window and, if available, a request ID from the retry log.
Frequently asked
Why do webhooks work in testing but stop in production?
The most common cause is a difference in TLS setup — a staging environment often uses a self-signed or internal certificate that works for local testing tools but is rejected by the provider in production. Confirm the production endpoint uses a certificate from a public certificate authority.
My endpoint returns 200 but I still see retries in the log — why?
Check response latency. Providers typically enforce a short timeout window (often a few seconds); if your handler does heavy processing before responding, it can time out even though it eventually returns 200. Acknowledge receipt immediately and process asynchronously.
Can I receive the same webhook twice?
Yes, by design. Providers retry on any ambiguous failure, including a slow response, so your endpoint should be idempotent — use the provider's message ID to detect and ignore duplicates rather than assuming exactly-once delivery.
How long are delivery attempts retried before they stop?
Retry windows vary by provider and event type, typically ranging from several attempts over minutes to hours. Check the retry log for the exact attempt count and interval shown for a given failed delivery.
My signature verification worked, then suddenly started failing — what changed?
This is almost always a change on your side: a new middleware layer, proxy, or framework upgrade that re-parses and re-serialises the request body before your signature check runs. Verify the raw bytes are passed unmodified to the hashing function.
Apply this to your own deployment
This guide describes decisions we make on live instances. Tell us your channels, systems and region and we will map it to an architecture outline, a provisioning plan and an indicative commercial model — usually within one business day.