--- title: "WhatsApp CRM Missing Phone Numbers: BSUID Explained" canonical_url: "https://www.calypso.so/answer-library/why-are-whatsapp-conversations-arriving-in-your-crm-without-a-phone-number" last_updated: "2026-09-14T00:33:52.931Z" meta: description: "WhatsApp webhooks now omit phone numbers unless recent contact exists. Here is why your CRM is silently creating duplicates, and how to fix matching for good." keywords: "WhatsApp BSUID, WhatsApp CRM no phone number, WhatsApp Cloud API webhook user_id, WhatsApp contact matching, WhatsApp LID username, REQUEST_CONTACT_INFO, WhatsApp duplicate contacts" "og:description": "WhatsApp webhooks now omit phone numbers unless recent contact exists. Here is why your CRM is silently creating duplicates, and how to fix matching for good." "og:title": "WhatsApp CRM Missing Phone Numbers: BSUID Explained" "twitter:description": "WhatsApp webhooks now omit phone numbers unless recent contact exists. Here is why your CRM is silently creating duplicates, and how to fix matching for good." "twitter:title": "WhatsApp CRM Missing Phone Numbers: BSUID Explained" --- Calypso home Answer Library / whatsapp-operations # **Why are WhatsApp conversations arriving without a phone number?** WhatsApp webhooks can arrive without a phone number. Learn the causes, the duplicates and broken attribution they create, and the fix: a stable contact id. ![Calypso Research](https://www.calypso.so/logo-calypso-icon.png) **Calypso Research** 13 min read· Updated September 13, 2026·3 sources **Short answer ** Since June 2026, WhatsApp Cloud API webhooks carry a business-scoped user id (BSUID) instead of a phone number. The number only appears if you contacted the person in the last 30 days or they are in your business Contact Book. A phone-keyed CRM matches nothing, creates a duplicate silently, and the damage surfaces later as broken attribution. ## The direct answer Your CRM is not broken. Since June 2026, Meta requires integrators to support business-scoped user ids (BSUIDs) — identifiers like US.1349… that replace the phone number as the canonical identity of a WhatsApp user. In Cloud API webhooks, the payload now carries user_id, from_user_id and recipient_user_id. The phone number only appears if one of two conditions holds: you have messaged or been messaged by that person in the last 30 days, or they exist in your business Contact Book. Otherwise the webhook arrives number-less. If your CRM keys contacts by phone number, a number-less payload matches nothing. Nothing errors — the payload is valid, the id is present, the message content is intact. The system does what it was designed to do: create a new record with whatever unique key it has. So every conversation with a customer you have not touched in over a month becomes a fresh contact, and the first signal you get is the same person appearing three times in a report. That silence is the defining feature of this failure. It produces no error logs, no failed webhooks, no dropped queues. ## Run this check this morning Before you speculate about causes, measure the damage. Filter contacts created in the last 30 days where the phone field is empty or malformed. If your tooling stores the webhook's raw payload, sort that cohort by created_at and scan the display names and message text. You are looking for the same human appearing under two or more records. The counts tell you which situation you are in. A handful of number-less records probably means edge cases: customers who blocked and unblocked you, restored phones, or contacts wiped from your book. A steady drip — say five to fifteen percent of new records with empty phones — means your integration is already living in the BSUID world and every cold or lapsed contact slips through unmatched. If you have a campaigns tool, cross-reference: contacts acquired through outbound blasts where no reply happened within 30 days are the richest source of duplicates, because by the time the customer finally responds, the number is gone from the payload. ## What actually causes the missing number There are three distinct causes, and they demand different responses. First, the platform change. Meta deliberately moved to business-scoped ids to decouple identity from phone numbers. The 30-day recency rule and the Contact Book are the only bridges back to a number. This affects every integration on the planet simultaneously; it is not something your team did. Second, your own data lifecycle. If someone deletes a contact from the business Contact Book, or a conversation goes quiet past the 30-day window, the number stops flowing. This cause is yours to manage, and it interacts badly with any process that archives or prunes contacts. Third, third-party tooling. Many WhatsApp inbox and CRM connectors were built on the assumption that from is a phone number and will remain one. Some vendor still runs a version predating the June 2026 requirement. Check which component in your chain — Meta, your BSP, your middleware, or the CRM itself — is dropping the number. Pull one raw webhook payload from the earliest point you control and see whether from or from_user_id is populated. Where the user_id exists but the number does not, the platform is behaving correctly and your identity layer is the gap. ## The second failure mode nobody instruments Missing numbers are only half the problem. BSUIDs rotate: when a customer changes their WhatsApp number, their business-scoped id changes with it, and WhatsApp announces the change through a user_id_update webhook. If you ignore that webhook, one customer becomes two records with two different ids and, eventually, two different phone numbers. Your merge tools will not catch this one, because neither record looks like a duplicate by phone or name. This is the failure that stays invisible the longest. Attribution quietly splits — half the purchase history lands on one record, the support thread on the other. Nobody complains because nothing looks wrong; the report just undercounts the customer. Instrument it explicitly: log every user_id_update event, and alert if your system receives one for an id it cannot resolve to an existing contact. That alert firing at all usually means your id mapping is already fragmented. ## Why you cannot just look the person up The instinct is to patch records manually: find the duplicate, look up the customer's number, fix it. WhatsApp has removed the lookup path. Usernames map onto WhatsApp's internal LID — there is no public directory, and search is exact-match only. You cannot type a partial name or a fragment of a username and find the person behind a number-less record. Either you know the identifier exactly or you do not get anything back. That has a practical consequence for your cleanup plan: every record you repair must be repaired from your own evidence — message content, order history, the customer telling you who they are — not from querying WhatsApp. Some gaps will simply not close. Budget for that rather than promising a full merge. ## Asking for the number is now a product decision From July 2026, REQUEST_CONTACT_INFO is the only sanctioned way to ask a user for their phone number. Before this change, many systems treated number capture as a database default — the number was just there. Now asking is an explicit interaction the customer can decline, and every ask costs attention in the conversation. Treat it like any other friction decision. When is the number actually necessary? For delivery logistics and account recovery, yes. For matching a returning customer to their record, only if your identity layer still depends on the number — which, if you follow the next section, it will not. Resist the urge to bolt an automatic REQUEST_CONTACT_INFO onto every first message. Customers notice, and opt-out rates in the first exchanges are unforgiving. ## The actual fix You do not need to replace your CRM. You need to change what a contact is keyed on. Today the phone number is doing two jobs at once: it is an attribute of the customer and it is the unique key that joins conversations to records. Split those jobs. Give each contact a stable internal id that your system controls. Store the phone number, the BSUID, and the username as attributes on that record — each one sufficient to match on its own, none of them load-bearing alone. When a webhook arrives, match on any of the three; fall through to creating a new record only when none match. When a user_id_update arrives, rotate the stored BSUID on the existing record instead of creating a new one. Say it plainly: most WhatsApp tooling has not done this yet. If you run a BSP or connector in your chain, ask your vendor directly how they handle BSUIDs and user_id_update. If the answer is a roadmap item rather than shipped behavior, you are the one holding the duplicates, so plan your own id layer accordingly. ## How to think about it going forward The uncomfortable truth is that phone-number matching was always a convenience Meta extended, not a contract. The 30-day window and the Contact Book make that explicit. Identity on WhatsApp now belongs to the platform's ids, and businesses keep a partial, expiring shadow of it. Operationally, that means the person who owns your contact data should own the id-mapping logic too, not leave it to whoever built the integration in 2023. Put two checks on a recurring cadence: number-less records as a percentage of new contacts, and unresolved user_id_update events. Both should sit near zero. When either climbs, you know within days instead of discovering it in a quarterly report as a customer with three names. ## Where this fits in daily operations Once identity is stable, the rest of the process gets simpler rather than more complicated. At Calypso, each WhatsApp conversation lands on a board with an objective, its own accumulated knowledge about the contact, and an agent that works the columns as steps — qualification, follow-up, handoff. None of that works when the contact underneath is a duplicate; the knowledge fragments and the agent re-asks what the customer already answered. That is the practical test of any fix: not whether the report looks cleaner, but whether the conversation picks up where it left off. A returning customer should land in the same column with the same history, whether they wrote yesterday or six weeks ago, whether the payload carried a number or not. The id layer is the unglamorous foundation under all of it, and it is the one thing worth fixing before the July deadline turns a reporting nuisance into a support backlog.**Sources ** Links used to ground claims in this answer. - **1** **WhatsApp CRM with Calypso**calypso.socalypso.so/use-cases/whatsapp-crm - **2** **WhatsApp Business Platform Cloud API — Webhooks**developers.facebook.comdevelopers.facebook.com/docs/whatsapp/cloud-api/webhooks/components - **3** **Meta Changelog — WhatsApp Business Platform**developers.facebook.comdevelopers.facebook.com/docs/whatsapp/changelog**From answer to product**## **Turn trusted knowledge into answers users can verify.** Use Calypso to organize sources, attach them to hosted agents, and answer across your website, workflows, and product UI with citations. [**See live demo **](https://www.calypso.so/demos) [**Get Started for Free **](https://whatsapp.calypso.so/join)