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?
Three steps, and the connection is verified rather than assumed.
- 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.
- Confirm the channel. Beam then “appears as an additional inbox channel. The CRM’s existing phone workflows remain separate and unchanged.”
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). If you run twenty sub-accounts, you run twenty workspaces, which is the behaviour you want when a client leaves.
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.
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.
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 chooses iMessage when the recipient is eligible and your selected line supports it; otherwise it uses text when that line can reach the recipient. This action does not force iMessage or guarantee RCS.”
Android leads are handled without you thinking about it. They get regular texts, and your CRM sees a beam-sms-sent tag instead of imessage-sent.
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, and the guardrails are the interesting part. 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. That single test tells you more than any demo. If you would rather talk it through first, Beam’s support page says a real person answers, usually within the hour during business hours (9am to 6pm Central, Monday through Friday).
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?
They get a regular text automatically, and your CRM sees a beam-sms-sent tag instead of imessage-sent. You do not need a separate branch in your workflow for it.
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.