Quick answer
Beam adds iMessage, RCS where supported and SMS fallback to a connected GoHighLevel workspace. Use a Custom Webhook for Beam workflow sends; the regular Send SMS action continues to use your default SMS provider.
For the broader agency overview, explore GoHighLevel messaging with Beam: iMessage, RCS, SMS fallback and separate client workspaces.
Key points
- GoHighLevel’s marketplace conversation providers cover custom SMS, email and call providers. There is no iMessage provider type, so blue bubbles come from an integration, not from GHL itself.
- Beam appears as an extra channel in the GHL conversation inbox. Your existing phone workflows stay separate and unchanged.
- GHL’s own Send SMS action does not route through Beam. It keeps using your default SMS provider. Workflow sends use a Custom Webhook step instead.
- A selectable “Send with Beam” Marketplace action is documented as still requiring publisher configuration and GHL publication. Do not plan around it yet.
- Beam picks blue when the recipient is eligible and your line supports it, and text otherwise. Ambiguous deliveries are never silently re-sent or downgraded.
- Capacity is real and it is a channel constraint, not an unlimited plan upgrade. Beam paces new outbound-first conversations to protect line health.
- Blue bubbles do not exempt you from registration, consent and opt-out obligations.
Can GoHighLevel send iMessages natively, or do I need a third-party app?
You need a third party. HighLevel’s marketplace documentation describes conversation providers as a way of “creating custom SMS, Email, and Call providers” (HighLevel marketplace docs). The word iMessage does not appear on that page at all. There is no blue bubble channel type to switch on inside a sub-account.
That is why every iMessage option for GoHighLevel is an integration. The integration holds the messaging lines and the delivery path, and GoHighLevel stays the system of record. Beam’s own framing is the same: “Beam is the messaging brain; your CRM stays the system of record” (routing docs).
How does Beam connect to a GoHighLevel location?
Connect contacts and calendars first, then install the inbox channel separately. A verified credential alone does not complete the inbox installation.
- Create a restricted credential in GoHighLevel. Beam’s docs say to “Give it only the contact and calendar permissions Beam needs.”
- Enter it in Beam Settings. Beam checks the live account before showing Connected. A stored credential without a successful read-back stays Not connected.
- Connect the inbox. Click Connect CRM inbox in Beam Settings and choose the same client account on the secure installation screen. Select Beam in the GHL conversation channel picker, then run the same-contact test below.
One workspace maps to one location, and that boundary is hard: “One Beam client workspace maps to one verified HighLevel location” and “A token for one location cannot read, write, or sync another client” (email and HighLevel docs). For an agency, each sub-account gets its own workspace and connection.
If your CRM is not GoHighLevel, Beam’s position is honest about it: “Other CRMs can be integrated through the API and documented events; not every CRM has a native connection.”
Full setup steps live in the CRM inbox messaging guide.
For teams also planning voice outreach, RizzDial’s guide covers connecting AI calling to GoHighLevel.
How do I send an iMessage from a GoHighLevel workflow step?
Keep your triggers, delays and conditions in GoHighLevel. Add a Custom Webhook action and point it at Beam’s workflow endpoint.
| Setting | Value |
|---|---|
| Method | POST |
| URL | https://beam.aisync.link/api/crm/workflows/send |
| Authorization header | Bearer YOUR_BEAM_WORKSPACE_TOKEN |
| Content-Type header | application/json |
The body carries the location ID, the GHL contact ID from the value picker, your sending line with its country code, the message, a request_key, a consent flag and dry_run. Two details matter more than the rest:
- You never paste a destination number. “Beam retrieves the phone number from this exact GHL contact in the connected location. You do not paste a separate destination number.” A conflicting duplicate-contact mapping stops the send for review.
- You validate before you send. Keep
dry_run: true, run your own test contact, and expectstatus: validatedwithqueued: false. No message goes out and the assistant is not paused. Then flip to false for that same test contact, and expect a message ID withstatus: queued. Beam’s docs are blunt about what that means: “This is acceptance, not delivery.”
Repeat the identical request with the same send key and Beam returns the same message ID with duplicate: true, without sending a second text. The key identifies one intended message rather than one contact, so a later step needs a different suffix. Do not generate a fresh random key on retry.
The step-by-step version with the full JSON body is in the GHL workflow guide.
Walkthrough: a workflow send and reply in one GHL conversation
This is a reproducible acceptance test from Beam’s workflow guide and CRM inbox guide, checked October 2026. It describes expected results, not a claim that your account has already passed.
- Prepare one contact you control. In the connected GHL location, create a test contact with an authorized phone and first name. Confirm consent, an active assigned Beam line and a workspace token with Send real messages permission.
- Open a draft workflow. Go to Automation → Workflows, add Custom Webhook, and label the step Send with Beam. This is a label you enter, not evidence of a published Marketplace action. Use the endpoint and headers above.
- Map the body below. Replace the location and sender placeholders. Use GHL’s value picker for contact ID and first name. Leave
assistant_modeaspreserveunless another responder must take ownership;pauserequires Control automation permission and has no automatic unpause. - Run the dry run. Execute only that contact with
dry_run: true. The response should showstatus: validatedandqueued: false; your phone should receive nothing. A validation error must be resolved before proceeding. - Send once. Set
dry_run: falsefor the same test. Record the returned message ID andstatus: queued. Watch for the message on the receiving phone and find the outbound entry on the same GHL contact. Pending is not delivered; inspect Beam’s recorded status if it does not arrive. - Reply from the phone. Send a distinct reply, such as “Test reply: Tuesday works.” In Conversations, open the original contact and verify that exact reply appears. Check the matching Beam thread too. An outbound success cannot prove inbound sync.
- Answer as a teammate. Select the Beam channel in the GHL conversation and send “Test complete, thank you.” Confirm it reaches the same phone from the expected line. Check that another assistant is not answering the same thread.
- Test duplicate and stop rules. Repeat the identical workflow request with the same key: expect the same message ID and
duplicate: true, with no second text. Test your stop-on-reply rule and an opt-out on the test contact before enabling the real workflow. Preserve suppression afterward.
{
"location_id": "YOUR_GHL_LOCATION_ID",
"contact_id": "{{contact.id}}",
"workflow_id": "welcome-v1",
"from": "YOUR_ASSIGNED_LINE_E164",
"message": "Hi {{contact.first_name}}, thanks for reaching out. How can we help?",
"request_key": "{{contact.id}}.welcome-v1.step-1",
"consent": true,
"assistant_mode": "preserve",
"dry_run": true
}The sender placeholder must become your assigned number including its country code. The recipient comes from the verified CRM contact, not a separate to field. For repeated appointments, use a stable appointment ID plus the step in the key; retrying one event must reuse its original key.
For a business-specific pilot, use real estate texting for showing inquiries or recruiting text messaging for interview coordination. Test one clearly identified inquiry or interview before extending the workflow to more contacts.
Troubleshooting the send-and-reply test
| What you see | What to inspect | Next action |
|---|---|---|
unauthorized or permission_denied | Token expiry, workspace and send permission | Replace or correct the workspace token in the authorization header |
crm_location_not_connected or crm_contact_not_verified | Selected location, connection read-back and contact ID | Reverify the client connection and map the intended contact |
sender_not_available | Assigned active line in this workspace | Select an available workspace line; do not borrow another client’s sender |
duplicate_crm_contact_requires_review | Conflicting contact identity | Resolve the duplicate before retrying |
contact_opted_out | GHL DND and Beam opt-out state | Stop sending; do not bypass suppression |
request_key_conflict | Changed text or settings under an existing key | Inspect the original send and correct the intended operation |
rate_limited, request_failed or an unclear result | Beam message record and workflow execution | Check whether a send occurred; retry only as appropriate with the same key |
| Queued response but no phone message | Sending window, pacing, line readiness and recorded delivery state | Keep the outcome pending until you have delivery evidence |
| Phone reply exists but no GHL reply | Inbox installation, selected location and original contact mapping | Compare the Beam thread with the GHL contact; inspect CRM webhook health |
| Another text arrives from the old sender | Native Send SMS steps or a second active automation | Trace both sends and pause the duplicate workflow before retesting |
Keep a masked record of the validation response, message ID, phone receipt and matching CRM conversation. Never capture authorization headers or customer conversations in training evidence.
Why does GoHighLevel’s Send SMS action not send through my iMessage provider?
Because it is not designed to. Beam’s docs state it plainly: “GHL’s regular Send SMS action does not select an additional Beam conversation channel. It continues using your default SMS provider.” The same page adds a warning worth repeating: do not switch that default just to configure the integration.
HighLevel’s own marketplace documentation explains the mechanism. For a provider added as a new conversation channel rather than a replacement, it says: “You can build premium workflow actions in your marketplace application. SMS module is not currently supported.” The native SMS module simply does not target an added channel.
That leaves two honest routes today: a Custom Webhook step, or a published Marketplace action. On the second, Beam’s documentation says a selectable Marketplace action named Send with Beam “still requires publisher configuration and GHL publication; do not assume it is available just because Beam appears in your conversation inbox.” Treat the webhook as the supported path and plan your workflows around it. Note too that HighLevel classes marketplace workflow actions as LC Premium Triggers and Actions, which are chargeable per execution on their side.
What happens when a GoHighLevel contact does not have iMessage?
Beam checks capability on first contact and remembers the answer, so you are not guessing per send. “Blue preferred. If the lead can receive blue-bubble messages they get a blue line, otherwise the text line.”
From a workflow send the wording is deliberately unheroic: “Beam sends from Apple and Android devices. It chooses iMessage when the recipient is eligible and your selected line supports it. RCS is used when the Android recipient’s phone and carrier support it; otherwise Beam falls back to SMS.”
For Android recipients, verify RCS or SMS on the receiving phone and the recorded send. The documented beam-sms-sent tag describes a text send, not proof that every Android recipient uses SMS.
Two behaviours to know before you design a workflow:
- Uncertain stays uncertain. Beam does not automatically re-send a blue message or switch it to SMS after an ambiguous provider update. A teammate makes any intentional follow-up from the inbox.
- Confirmed-dead is a setting. A workspace can choose whether a dead blue bubble message is automatically re-sent as a text from the SMS line, or left for a human, keeping the experience blue-bubble only.
You can also screen a list for blue bubble reachability before you build the campaign, up to 25,000 numbers per check, with results reused for 24 hours. More on that at checking iMessage availability.
Which CRM tags does Beam write back to GoHighLevel?
Tags are how this integration earns its place, because they fire the automations you already built.
| Tag | Meaning |
|---|---|
imessage-sent | The first blue-bubble message went out. |
beam-sms-sent | The lead’s phone does not support blue bubbles, so a text went out instead. |
imessage-replied | The lead replied. Beam’s docs call this “your hottest signal.” |
bot-booked-call | The assistant confirmed a booking, or confirmed a window in tag-only mode. |
bot-handoff | The conversation needs a human. |
Delivery states are conservative on purpose: “The CRM receives only pending, delivered, or failed states backed by Beam’s recorded send path. Beam does not invent open or read status.”
How does Beam handle sending capacity?
Beam paces new outbound-first conversations to protect line health. Capacity is a channel constraint rather than an unlimited plan upgrade, and the right rollout depends on the condition of the assigned lines, list quality, and how the conversation starts.
Replies inside an active thread do not create another first touch. Conversations the contact starts are handled differently from outbound-first outreach. Plan the campaign around pacing and healthy lines rather than a promised universal daily number.
One important exception: when the contact texts you first, the ramp does not apply, and there is no warm-up ceiling on answering someone who reached out. That is why the text-us-first funnel is usually the better first build. Full detail on limits at iMessage sending limits.
Do blue bubble sends skip A2P registration, consent and quiet hours?
No. Beam’s documentation says “Registration depends on the channel and number type. Do not assume SMS traffic is exempt from A2P registration or verification.”
Opt-out handling is enforced at the send layer, not left to a workflow. STOP, UNSUBSCRIBE, QUIT, CANCEL, END, REVOKE and REMOVE all work, and so does ordinary language such as “please stop texting me”. An opted-out contact is blocked at the send layer, so nothing further goes out, including assistant replies and scheduled follow-ups, and a contact.opted_out event fires to your webhooks. Beam also checks GHL DND and local opt-out state before a workflow send.
Sending respects a window, 9am to 8pm by default, with the assistant answering between 8am and 10pm. None of this is legal advice, and Beam says so on its own compliance page. More at iMessage and A2P registration.
Can an AI assistant reply and book on the calendar?
Yes. Before every reply the assistant reads the calendar’s live availability for the next six days and proposes two real windows in natural words, and it never sends a calendar link. A thread is only marked booked after the calendar confirms the appointment. If the calendar write fails after a lead agreed, the assistant pauses itself and alerts your team to lock it in manually.
Without a calendar selected it runs in tag-only mode, confirming a window in words and tagging bot-booked-call so your own GHL workflow does the booking. An angry lead, a legal topic, a refund decision, a stop request or a human takeover pauses assistant activity for that conversation.
More at the AI text assistant.
What should an agency know before committing?
Per-client separation is the part that matters at scale: each client or reseller runs in its own workspace with a separate inbox, numbers, assistant, team, CRM connection and API key, and nothing crosses between workspaces.
Be aware of the current state as documented. Custom domains are not active, and agency pricing and rebilling terms are not published or implemented. Clients pay Beam directly today, even when an agency created the workspace. See iMessage for agencies for the full picture, and is business iMessage allowed for the continuity question.
A sensible next step
Read the CRM connection guide and the workflow send guide, then run one dry-run webhook against a test contact you own in a draft workflow. Use that test to validate the connection before rolling the workflow out to client accounts. For the exact request body and a generic CRM version of the same pattern, see send iMessage from a CRM.
Use the GoHighLevel texting guides to test reminders, sender identity, replies and client handoffs, or go straight to iMessage automation to automate the reminder and follow-up side of the workflow.
For the business rollout, start with iMessage for business, map the iMessage CRM workflow, and check RCS business messaging and fallback for Android recipients.
FAQ
Does GoHighLevel support iMessage out of the box?
No. HighLevel's marketplace documentation describes conversation providers for custom SMS, email and call providers, and does not list an iMessage provider type. Blue bubble messaging in GoHighLevel comes from an integration that holds the lines and the delivery path while GoHighLevel remains your CRM.
Can I use GoHighLevel's Send SMS action to send a blue bubble?
No. Beam's documentation states that GHL's regular Send SMS action does not select an additional Beam conversation channel and continues using your default SMS provider. Use a Custom Webhook workflow step pointed at Beam's workflow endpoint instead, and do not change your default SMS provider to try to force it.
Is there a Send with Beam action in the GoHighLevel Marketplace?
Beam's documentation says a selectable Marketplace action named Send with Beam still requires publisher configuration and GHL publication, and warns against assuming it is available just because Beam appears in your conversation inbox. Build on the Custom Webhook path today.
What happens if the contact is on Android?
Beam uses RCS when the Android phone and carrier support it, with SMS fallback for other reachable recipients. Check the recorded channel and the receiving phone; a CRM tag alone does not establish the delivery route.
How does Beam handle sending capacity?
Beam paces new outbound-first conversations to protect line health. Replies inside an active thread and conversations the contact starts are handled differently. Capacity is a channel constraint, not an unlimited plan upgrade.
Do I still need A2P registration and consent records?
Assume yes until you have confirmed otherwise for your assigned lines. Beam's docs say registration depends on the channel and number type, and to not assume SMS traffic is exempt. Opt-outs are enforced at the send layer and GHL DND is checked, but Beam does not capture marketing consent for you.
Can Beam send from my personal Apple ID?
No. Beam sends from dedicated business numbers, which keeps your personal identity separate and your business messaging manageable by a team.
What does the lead see?
A normal conversation from your dedicated number. Beam's FAQ states there is no branding, no watermark, and nothing that says a platform is involved.