Who this is for
Workspace admins who use the GoHighLevel integration and want outbound messages from GHL to hit both an Android SMS relay and a linked WhatsApp instance, or to switch behavior after the contact replies.
Applies to messages InfiniReach receives from GHL through the conversation provider (including delivery URL traffic and compatible outbound webhooks). The same routing rules apply across those paths.
1. Open routing for the location
Integrations → GoHighLevel → your location → Configure Routing
- Expand the location card and open the routing panel.
- Under Default Route (Fallback), choose SMS + WhatsApp when you want dual delivery whenever no higher-priority rule matches.
- Pick the SMS device / SIM leg and the WhatsApp instance leg. Both are required for a valid dual default route.
- Use + Add Rule to route specific countries, local (+1) numbers, or individual numbers to SMS, WhatsApp, or SMS + WhatsApp. Rules are evaluated top to bottom; the first match wins.
- Click Save Default Route after changing defaults, dual-reach options, or tag settings.
2. Dual reach mode
In the Dual reach & message tags section (same routing screen):
- Always send both channels — Every eligible outbound from GHL sends WhatsApp (where configured) and SMS, using the device and instance from the matched rule or default route.
- Reply lock (broadcast lock) — After the contact sends an inbound message on either SMS or WhatsApp, InfiniReach remembers that channel for the conversation. The next outbound from GHL for that conversation is sent on the locked channel only (until the lock is cleared or expires).
Reply lock only applies when your matched rule or default route is configured as SMS + WhatsApp (a full dual destination). Pure SMS or pure WhatsApp routes are unchanged.
3. Lock TTL (optional)
When Reply lock is enabled, you can set Lock TTL (hours). If set, a lock older than that many hours is ignored and dual routing can apply again for that conversation. Leave the field empty if you do not want time-based expiry.
4. Per-message route tags (optional)
Enable Allow leading route tags in the message body to let staff prepend a directive. The tag is removed before the message is sent to the carrier or WhatsApp.
| Tag (start of body) | Effect |
|---|---|
| [route:whatsapp] | Force WhatsApp for this send, if your rule or default allows WhatsApp for that target. |
| [route:sms] | Force SMS for this send, if your rule or default allows SMS for that target. |
| [route:dual] | Force both channels when the route includes a configured SMS + WhatsApp pair. Using [route:dual] also bypasses reply lock for that message so both legs can send. |
Tags must be lowercase and placed at the very beginning of the message body, followed by whitespace. Invalid or unsupported tags are ignored (the full body is sent as usual).
5. Clear a reply lock
In the dashboard, when Reply lock is enabled, the routing panel includes a Clear reply lock section: enter the GHL conversation ID (recommended) and/or the contact's E.164 phone number, then click Clear lock.
For automation or external tools, use the workspace-authenticated HTTP API (same session as the dashboard, not the public X-API-Key SMS API):
If conversationKey is omitted, the server builds a key from conversationId and/or normalized to (E.164). The response includes clearedKey so you can confirm which key was removed.
6. Verify end-to-end
- Confirm the SMS device is online and the WhatsApp instance shows connected in InfiniReach.
- Send a test outbound from GHL with dual default or a dual rule; you should see both SMS and WhatsApp attempts in message history where applicable.
- With reply lock on, reply once on one channel only, then send from GHL again—the second send should stay on that channel unless you use
[route:dual]or clear the lock. - With tags enabled, send a body starting with
[route:sms]and confirm the WhatsApp leg is skipped.