Whatsapp

Please add feature that every Staff member can have their own WA number to chat from wihtin GHL

As of June 2026, Meta is rolling out WhatsApp usernames, allowing users to hide their phone numbers by default. When a user adopts a username, businesses will no longer receive their phone number via webhook. Instead, Meta will deliver a Business Scoped User ID (BSUID), a unique identifier per business account. Currently, GHL identifies and matches contacts exclusively by phone number. This means that once a contact adopts a WhatsApp username and hides their number, any incoming message from that contact will either fail to match an existing contact record, create a duplicate, or simply land as an unassigned conversation in the inbox. For businesses using GHL with direct Meta integration, this is not a hypothetical edge case. It will affect real conversations, automations, and workflow triggers that rely on contact identification. Requested solution: Store and index the BSUID returned by Meta's webhook as a secondary contact identifier, alongside the phone number. When an incoming WhatsApp message carries a BSUID, GHL should attempt to match it against existing contacts before creating a new record. This would preserve conversation history, workflow context, and contact data integrity as Meta's username rollout expands. This is a foundational fix that will become increasingly necessary as WhatsApp username adoption grows throughout 2026 and beyond.

As of June 2026, Meta is rolling out WhatsApp usernames, allowing users to hide their phone numbers by default. When a user adopts a username, businesses will no longer receive their phone number via webhook. Instead, Meta will deliver a Business Scoped User ID (BSUID), a unique identifier per business account. Currently, GHL identifies and matches contacts exclusively by phone number. This means that once a contact adopts a WhatsApp username and hides their number, any incoming message from that contact will either fail to match an existing contact record, create a duplicate, or simply land as an unassigned conversation in the inbox. For businesses using GHL with direct Meta integration, this is not a hypothetical edge case. It will affect real conversations, automations, and workflow triggers that rely on contact identification. And also on mobile apps(Lead Connector) with WhatsApp Business API was unable to reply due to it's not number but it's an username, it's showed no message initiated from the user in past 24 hrs. Please use a template to initiated a chat but even tho still under 24 hrs free window chat. Requested solution: Store and index the BSUID returned by Meta's webhook as a secondary contact identifier, alongside the phone number. When an incoming WhatsApp message carries a BSUID, GHL should attempt to match it against existing contacts before creating a new record. This would preserve conversation history, workflow context, and contact data integrity as Meta's username rollout expands. This is a foundational fix that will become increasingly necessary as WhatsApp username adoption grows throughout 2026 and beyond.

Would really love the ability to have whatsapp calls recorded within GHL. Many industries require call recordings in order to comply with regulators and governing bodies, and many clients (south african based) prefer to use whatsapp calling over regular phone calls as contactability is 60% higher when whatsapp calling. Meta recently updated the API to allow for recording of whatsapp calls. Is this something we can expect in the (very) near future?

As an addon to the upcoming WhatsApp integration - can we have the ability to receive form responses as WhatsApp messages from customers and build automated follow-up sequences based on field values. These do a good job in converting the form submission into a WA message for further conversation. https://whatsform.com/

You can now create WhatsApp carousels in the business API. It would be great if we were able to do this here

Currently whatsapp personal and whatsapp business allows for group/ broadcast group creation. Please add this functionality to GHL whatsapp so we can add groups to our marketing strategies.

Disconnection Bug Fix Request: Clean WABA Disconnect / Credit Line Removal HighLevel should allow businesses to cleanly disconnect their WhatsApp Business Account and revoke the shared credit line when changing BSP/provider. Currently, businesses need to delete and recreate their WABA just to move providers. This creates serious risks around operational continuity, chat history, data ownership, and customer trust. WhatsApp is often where businesses manage sales, support, bookings, billing, and customer records. Users should not be locked into a provider or forced to rebuild their WABA to switch. Meta documentation do support revoking a shared credit line: https://developers.facebook.com/documentation/business-messaging/whatsapp/solution-providers/share-and-revoke-credit-lines/#revoke-a-shared-credit-line Requested fix: Enable clean WABA disconnect and shared credit line revocation, so businesses can migrate BSPs without deleting and recreating their WABA. At minimum, this limitation should be clearly disclosed before users connect their main WhatsApp number.

This should be no different to facebook, instagram, gmb (whatever it now is), tiktok etc and emails. WhatsApp should be included within the subscription cost!

Tested this recently trying to replicate an AI agent + WhatsApp automation setup across multiple sub-accounts for different real estate agents under one agency. Two separate problems, both add significant manual work per sub-account: The template often doesn't transfer at all when pushed via Snapshot, despite Snapshot documentation stating WhatsApp Templates are supported and auto-submitted to Meta for approval on import. In my case, the destination sub-account simply had no trace of the template after loading the snapshot, had to manually recreate and resubmit from scratch. Even in cases where the template does successfully copy over, it still has to be manually selected inside every individual workflow that references it, and the WhatsApp number for that sub-account also has to be manually reselected in each flow. So even a successful template transfer doesn't actually save the time it's supposed to, since the workflows still need to be touched by hand afterward. For agencies replicating the same system across many sub-accounts (in my case, multiple agents under one real estate brokerage, with more planned), this turns what should be a one-click snapshot push into hours of manual per-account cleanup, both fixing missing templates and rewiring every workflow. Requesting this be looked at as one combined issue: reliable template transfer on snapshot push, and automatic binding of transferred templates (plus the sub-account's own WhatsApp number) into any workflow steps that reference them, without manual reselection.