Not Receiving Incoming Messages

Incoming WhatsApp messages not appearing in the inbox is almost always a break in Meta's webhook delivery to VGraple CRM, not a problem with the customer's message or your number's ability to receive it. The good news is that every event Meta does deliver is durably persisted and retried on failure, so once the connection is fixed, very little is genuinely lost.

Symptom

Customers report messaging your WhatsApp number, or you can confirm on the WhatsApp Business app itself (for a coexistence connection) that a message arrived, but it never appears in the VGraple CRM inbox. Nothing else about the channel necessarily looks wrong: sending can still work normally in some failure modes, since sending and receiving depend on partially different pieces of the connection. There is usually no visible error to the customer at all, which makes this one of the more disorienting failures, since from the outside everything appears to be working.

Why it happens

Every inbound WhatsApp event, a message, a delivery status, a template status change, reaches VGraple CRM only because Meta has been told, through a webhook subscription registered on the WhatsApp Business Account, to deliver events to a specific URL. If that subscription is missing, was never completed, or was dropped (which can happen silently during certain account or portfolio changes on Meta's side), Meta has nowhere to send the event, and the message simply never leaves Meta's infrastructure toward VGraple CRM at all; it is not delayed or queued anywhere retrievable. Meta also requires the webhook endpoint to prove its identity twice: once at subscription time, when Meta calls the URL with a verification token that must match what is registered for that channel, and on every subsequent delivery, via a signature Meta computes using the WhatsApp Business Account's app secret. A mismatch on the signature check, most often from a decrypted secret becoming out of sync after certain account changes, causes VGraple CRM to reject the delivery rather than accept it.

A second, less common cause is the access token behind the connection becoming invalid; while this shows up more visibly as failed sends (error 190), some related account operations depend on the same token and can be affected together.

Fix

1. Check the WhatsApp channel's connection status in Settings, then Channels, then WhatsApp. A token or connection problem shows as "needs attention" here before it necessarily shows up as a specific missing-message symptom.
2. Confirm sending still works from that number. If sends succeed but nothing incoming arrives, this narrows the problem specifically toward the webhook subscription rather than the token, since a token problem (error 190) typically affects both directions.
3. For a coexistence connection, confirm the WABA subscription state. VGraple CRM verifies and self-heals this automatically before any sync request, but a subscription that was dropped between checks can still cause a temporary gap; reconnecting through the channel settings re-establishes it.
4. If the channel shows connected and the token is valid but messages still are not arriving, contact support rather than continuing to troubleshoot from the business side; a dropped webhook subscription with no other visible symptom generally needs the connection re-verified against Meta directly.
5. Once fixed, check whether the customer's original message needs a manual follow-up. Meta does not typically re-deliver an event it already attempted and had rejected (a signature mismatch, for example) once the underlying issue is fixed; messages that never left Meta's side because of a missing subscription similarly are not backfilled once the subscription is restored.

How VGraple CRM handles it automatically

For coexistence connections, the WABA webhook subscription is checked and, if missing, re-registered automatically immediately before requesting a chat history or contact sync, specifically because a missing subscription there is especially costly: the one-time history sync would otherwise be sent into the void with genuinely no way to request it again outside a fresh 24-hour onboarding window. Every webhook event that does reach VGraple CRM's servers, regardless of channel, is persisted to storage in a single fast database write before any processing begins, and only then acknowledged back to Meta; if processing fails partway through afterward, a scheduled retry attempts it again, for up to five attempts across a 72-hour window, so a transient processing error on VGraple CRM's own side cannot silently lose an event that Meta did successfully deliver. Every inbound signature is verified against the channel's own decrypted app secret before any processing occurs, rejecting anything that does not match rather than processing an unverified payload.

Prevention

Avoid making unrelated changes inside the Meta Business Portfolio that touch the WhatsApp Business Account's permissions or connected apps once the number is live and receiving messages, since these are the changes most likely to disturb a working webhook subscription as an unintended side effect. For a coexistence connection specifically, be aware that the one-time history and contact sync window is only open for 24 hours after a fresh onboarding, so if a subscription issue is suspected during that window, resolving it quickly matters more than for an established, steady-state connection. Regularly glancing at channel health rather than only checking it when something already seems wrong catches a token or subscription problem before it produces a customer-facing gap.

Is anything ever unrecoverably lost?

Once an event genuinely reaches VGraple CRM's webhook endpoint, essentially nothing is lost: it is persisted before processing and retried automatically on any downstream failure. What can be genuinely unrecoverable is an event Meta never successfully delivered at all, because the subscription was missing or a signature check rejected it outright before storage, since in that case there was never anything on VGraple CRM's side to retry from. This is exactly why the fix for this symptom focuses on restoring the connection quickly rather than searching for a recovery mechanism afterward; the events that matter here live entirely on Meta's side until the moment of successful delivery, not in any queue VGraple CRM controls.