> ## Documentation Index > Fetch the complete documentation index at: https://docs.dmly.io/llms.txt > Use this file to discover all available pages before exploring further. # Fix no inbound messages > Your WhatsApp number says connected but nothing reaches the Inbox — how to tell whether Meta is calling DMLY at all, and what to fix. The channel shows as connected. You can send a message out. But when a customer writes to your number, nothing appears in the [Inbox](/inbox/overview) — and no error appears anywhere either. This page is about that exact symptom on WhatsApp, and the order to check things so you don't waste an afternoon on the wrong end of the problem. **If the Meta app is your own, the usual cause is a setting inside it that DMLY cannot see or change.** Inbound messages only reach DMLY if your Meta app has a webhook configured at the app level — a callback URL, plus a subscription to the **messages** field. Meta's API does not let DMLY read that setting or write it. There is no button in DMLY that fixes it and no reconnect that repairs it. So if your number is registered and subscribed and messages still don't arrive, stop looking in DMLY. The fix is in the Meta App Dashboard, and everything below is about getting you to that conclusion quickly — or ruling it out. ## Does this page apply to you? Most of what follows is about the app-level webhook inside a Meta app, and that only matters if the Meta app is yours. It is yours if you connected with **Bring your own WhatsApp Cloud API keys — Complex (30 mins)**. The app-level webhook is then yours to set, and every check below is something you can do. If you connected with **Configure WhatsApp via Embedded Signup — Simple (10 mins)**, whose button reads **Connect a WhatsApp number**, the Meta app isn't yours and its webhook isn't part of your setup. The two causes that apply to you are [registration is not verification](#registration-is-not-verification) and [the double-connect trap](#the-double-connect-trap). If you don't remember which you used, it's almost certainly the guided one. It's the default and it takes ten minutes. ## Start here: has anything ever arrived? Open **Configurations → Logs**, select **Filters**, and set **Event** to **Messages** and **Status** to **Success**. Every inbound message writes one row here, reading `Inbound WhatsApp message from …`. Logs only ever shows the channel you currently have selected, so make sure the WhatsApp number you're chasing is the selected one before you read anything into an empty list. See [Reading the Logs page](/troubleshooting/logs). Three outcomes, and they send you to different places: | What you see | What it means | | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Rows, but they stop at a certain date** | Messages used to arrive. Something changed on that date — a reconnect, a new number, a change in Meta. Go to [the double-connect trap](#the-double-connect-trap) first. | | **No rows at all, ever** | Meta has probably never called DMLY for this number. This is the webhook-object case. Work through the checks below. | | **No Success rows, but Error rows saying `Inbound WhatsApp webhook dropped`** | Meta *is* calling DMLY and DMLY is rejecting the call. Skip ahead to [reached DMLY and got dropped](#reached-dmly-and-got-dropped) — this is a different problem with different fixes. | That last row is the most valuable thing on this page. An `Inbound WhatsApp webhook dropped` entry proves the connection between Meta and DMLY exists. Its absence, combined with silence, means the two are never speaking. ## The order to check Open **Bot Setup → WhatsApp → Configuration** and find the **Number registration** row. It reads either **Registered** or **Not registered**. If it says **Not registered**, that is your answer and nothing else matters yet — the page tells you as much: *"This number isn't registered for WhatsApp Cloud API yet, so it can't send or receive messages. Register it with the 6-digit PIN to go live."* Select **Register phone number** and enter the six-digit two-step verification PIN for that number. If Meta rejects it, DMLY says so rather than pretending it worked — the two usual reasons are a wrong PIN, or the number already being registered to a different Meta app. Read [registration is not verification](#registration-is-not-verification) before you decide this step is fine. It is the single most common false negative. If this number has ever been disconnected and reconnected, DMLY may be holding two records and showing you the wrong one. See [the double-connect trap](#the-double-connect-trap). DMLY subscribes itself to your WhatsApp Business Account when you connect the number. If Meta rejects that subscription, the number still connects and looks fine — but never receives anything. If you brought your own keys, DMLY warns you on screen at connect time and names the two reasons: the token needs the WhatsApp business management permission, and the number must be registered rather than pending. Fix whichever applies to your token or your number, then connect the number again. If the number is registered, the account is subscribed, and messages still don't arrive, you are at the cause named at the top of this page. Nothing in DMLY is wrong. Open **Integrations → WhatsApp → Configuration** and find **Webhook Settings**. Use **Copy URL** and **Copy Token** — the page's own instruction is to paste the URL *"exactly as shown, with no trailing slash"*, and then subscribe the **messages** field. Copy the URL from that page rather than typing it: a trailing slash turns it into a per-account URL with an empty token, which misroutes. ## Registration is not verification This is the trap that costs people the most time. **Number verification** and **Display name status** are different things from **Number registration**. A number can be verified, with an approved display name, showing every green tick you'd expect — and still not be registered for WhatsApp Cloud API. A number in that state can neither send nor receive. So when you look at **Bot Setup → WhatsApp → Configuration**, read the **Number registration** row specifically. Do not read **Number verification** and conclude you're fine. They are not the same field and they do not imply each other. If **Number registration** says **Not registered**, everything else on this page is noise. Fix that first with **Register phone number** and the six-digit PIN, then re-test by sending a message to the number from a phone. ## The double-connect trap DMLY files a connected number under its WhatsApp phone number ID. That has a consequence people hit constantly: **Reconnecting a number to a different WhatsApp Business Account does not replace the old record — it adds a second one.** The old one stays behind, still pointing at the account you left. **Integrations → WhatsApp** always shows the most recently connected record. But on **Bot Setup → WhatsApp → Configuration** it is the channel picker that decides which record you are acting on — **Register phone number** and **Disconnect WhatsApp** both target the selected channel's number, so selecting a stale channel means acting on the stale record. That explains a whole family of confusing symptoms: * Messages arrived until the day you reconnected, then stopped. * The **WABA ID** shown on **Configuration** isn't the one you expect. * You disconnected the number, but something still looks connected. One **Disconnect WhatsApp** removes one record. If a reconnect left duplicates, the leftovers survive and have to be disconnected separately: select each WhatsApp channel in turn on **Bot Setup → WhatsApp → Configuration**, compare the **WABA ID** on each, and disconnect the ones pointing at an account you no longer use. ## Reached DMLY and got dropped If **Logs** shows `Inbound WhatsApp webhook dropped` under **Messages** + **Error**, Meta is calling DMLY successfully and DMLY is turning the message away. Open the row; the details carry the reason: **the signature doesn't match** — the app secret DMLY holds for this number doesn't belong to the Meta app that is sending the webhook. Reconnect the number using the keys from the same app whose webhook you configured in Step 4. Either way, this is a better place to be than silence. A dropped webhook is a wiring mismatch you can find. No webhook at all is a setting that doesn't exist yet. ## Next Where the inbound rows and the dropped-webhook rows live. The 24-hour window and messaging tiers — why sending fails, rather than receiving. When the raw error from Meta says the account itself is the problem. The two connect paths, and what each one sets up for you.