Running Multiple WhatsApp Numbers in One GHL Sub-Account (Routing Done Right)
How to manage 5+ WhatsApp numbers per GHL sub-account, route messages by override tag or user assignment, connect via pairing code, and automate reconnects.
June 12, 2026 Β· 7 min read Β· GoGHL Team
A single WhatsApp number shared across a sales team, a support team, and three sales reps creates three compounding problems: routing ambiguity (who owns this conversation?), risk concentration (one ban takes everything down), and persona confusion (the support number should not be closing deals).
GoGHL gives every sub-account five WhatsApp numbers as a baseline, with additional numbers at $9 per month each. More importantly, it ships a deterministic routing chain that resolves which number sends each message - without requiring any manual dispatch logic in your workflows.
This guide covers why agencies structure their number setups the way they do, the exact routing priority chain, QR-less pairing-code login for remote team onboarding, the residential proxy rules that protect those numbers, and the disconnect-alert system that catches problems before they become outages.
Why Agencies Run Multiple Numbers
Role separation, risk isolation, and rep-level attribution are the three reasons agencies end up with multiple numbers. Role separation means sales messages come from the sales number, support messages come from the support number, and broadcast campaigns come from a dedicated outbound number. Contacts who save "Support - [Client Name]" in their phone have a different relationship with that contact than with "Sales - [Client Name]". The number is part of the brand identity at the contact level.
Risk isolation is the more urgent operational reason. WhatsApp's trust scoring operates at the phone-number level. If a broadcast campaign triggers a spam report spike, the affected number may receive a temporary restriction while other numbers continue operating. An agency that runs all client communications through one number has no fallback. An agency with four active numbers loses 25% capacity, not 100%.
Rep-level attribution solves a workflow problem: when a sales rep handles a conversation from their personal WhatsApp number and the CRM never sees it, that pipeline data is lost. Assigning each rep a dedicated instance means every message they send is logged, routable, and auditable in the CRM.
Pricing and Instance Limits
Every GoGHL sub-account plan includes 5 WhatsApp numbers. This is not a per-agency limit - each sub-account gets 5. An agency managing 20 client sub-accounts has up to 100 numbers available before paying for extras.
Additional numbers cost $9 per month per number, billed per sub-account, and only for active (connected) numbers. A sub-account with 8 numbers connected pays $27 per month in add-ons ($9 Γ 3, since the first 5 are included). Disconnecting a number stops its billing.
Pricing summary: - 5 WhatsApp numbers included per sub-account - Additional numbers: $9/month each (active numbers only) - Example: 8 numbers = $27/month add-on (5 included + 3 extra) - One agency install covers all sub-accounts - no per-sub-account platform fee - See full plan details at goghl.ai
The Routing Priority Chain
When a workflow or manual message fires, GoGHL resolves which number to use through a five-step priority chain. Understanding this chain is what separates a well-architected multi-number setup from one that sends sales messages from the support number.
The chain runs in order from highest to lowest priority. The first rule that matches wins.
- Use { WA#2 } in workflow message bodies to force a specific number for that send only
- Use the wa: +number tag on a contact to permanently associate them with a number - good for rep ownership
- Assign contacts to users in GHL and configure each user's default instance to get automatic rep-level routing
- Set one instance as the default for the location to catch any contacts not covered by rules 1β3
- Error 106 means no number was available - check that at least one instance is connected and set as default
Outbound routing priority chain (verbatim from GoGHL docs): 1. Manual override in message body: { WA#N } Example: 'This message will go via 2nd instance { WA#2 }' (The { WA#2 } tag is stripped before the message sends) 2. Contact tag: wa: +15551234567 (Locks the contact to that specific number; old wa: tags auto-removed when the number changes) 3. Contact's assigned user's instance (The user assigned in CRM owns the number relationship) 4. Default instance (One designated default per location) 5. Any available connected instance (Fallback - if no number is available: Error 106, message fails)
QR-Less Login via Pairing Code
Traditional WhatsApp Web linking requires the person connecting the number to scan a QR code from the linked device. For agencies onboarding remote team members or clients who are not technically confident, QR scanning is a friction point that causes delays and support tickets.
GoGHL supports phone-number login, which replaces the QR scan with an 8-character alphanumeric code. The process does not require the person connecting the number to access the CRM dashboard at all - they only need their phone.
This is the right path for agencies who want to onboard a client's WhatsApp number without screen-sharing sessions or waiting for the client to figure out where the QR code is.
Pairing code login steps (verbatim from GoGHL docs): 1. GoGHL β Manage β 'Log in with phone number' 2. Enter country and number 3. Receive 8-character code (example format: QDV8-CG7V) - time-limited 4. On the phone: WhatsApp β Settings β Linked Devices β Link a Device 5. Tap 'Link with phone number instead' 6. Type the 8-character code Note: one WhatsApp account per instance. The code expires - complete the process promptly after generation.
Residential Proxies: One Per Instance, Free
WhatsApp's trust infrastructure monitors connection metadata, including IP address and ISP type. A WhatsApp session connecting from a datacenter IP in a country that does not match the device's physical location is a pattern that triggers heightened scrutiny.
GoGHL includes one residential proxy per WhatsApp instance at no extra charge, routed through real residential ISP IPs in 195+ countries. The latency is documented as typically under one second, which is imperceptible in normal messaging flows.
The proxy location should match the physical location of the device, not the number's country of origin. If the team member is physically in the US, use a US proxy. If they travel, update the proxy location to match.
Two rules that cannot be bypassed: one proxy per instance (you cannot stack multiple proxies on one number), and do not combine the proxy with a VPN. VPNs create conflicting IP signals that can trigger the same scrutiny the proxy is designed to avoid. If a team member travels and changes physical location, update the proxy location to match.
The recommended combination for high-volume accounts is residential proxy plus smart drip mode at 15-second intervals plus spintax message variation. Each layer addresses a different trust signal.
Disconnect Alerts and Self-Healing Workflows
A disconnected WhatsApp number is an invisible outage. Workflows keep firing, messages queue up, and the only indication is Error 106 responses - which are easy to miss if no one is actively monitoring the dashboard.
GoGHL's disconnect notification system sends alerts via both email and WhatsApp to up to three recipients: the account's primary WhatsApp number (set in Profile Settings), the disconnected instance's own number (fixed), and one optional custom number per location. Setup is in Integration Dashboard β Location β Settings tab β Notification Settings card.
The 'WhatsApp Disconnected' workflow trigger takes this further. It fires on any disconnect, intentional or unexpected, and exposes four payload variables that let you build automated recovery logic.
- Use the phoneNumber payload variable to send a Slack or email alert that names the exact disconnected number
- Use the instanceIndex to auto-create a high-priority task in GHL with the instance number in the title
- Route the alert to your agency operations channel, not just to the client - agencies catch disconnects before clients do
- Pair with the iMessage channel or SMS as the outbound medium for the alert itself, since the WhatsApp number is offline
- Consider a daily health-check workflow that verifies all instances are connected and fires a proactive alert if any show no outbound activity in 24 hours
WhatsApp Disconnected workflow trigger - payload variables (verbatim from GoGHL docs): {{whatsapp_disconnected_prod.payload.instance.phoneNumber}} - e.g. +1234567890 {{whatsapp_disconnected_prod.payload.instance.instanceIndex}} - e.g. 1 {{whatsapp_disconnected_prod.payload.channelType}} - whatsapp {{whatsapp_disconnected_prod.locationId}} Found in: Workflows β Apps tab β WhatsApp provider Caveat: cannot send WhatsApp via the disconnected number in this workflow - use email, SMS, or a different connected WhatsApp instance for outbound alerts.
Multi-number WhatsApp operations are an agency competency, not just a feature. The agencies that get this right build routing logic into their sub-account templates, document their proxy location rules, and have a disconnect recovery workflow running before the first number ever drops. Start with the routing chain - if you cannot answer 'which number sends this message?' for every workflow in a sub-account, that is the first gap to close. The GoGHL integration handles the infrastructure; the routing architecture is the part that requires deliberate design.
Try it inside your own GHL account
One install adds WhatsApp, iMessage, and SMS to every sub-account. Free for 7 days, no credit card.