Ad Reporting and Attribution

When a custom phone provider is selected, the Phone Numbers → Verify Bundle flow does not work. Switching the provider back to Lead Connector immediately restores the ability to verify the bundle. This forces agencies to temporarily change providers just to complete bundle verification. Environment Area: Settings/Telephony → Phone Numbers Configuration: Custom phone provider enabled (e.g., myCRMSIM) Region/Context: AU phone numbers requiring a regulatory bundle verification Preconditions Account has a custom phone provider selected and saved. There is an AU phone number that requires Reg Bundle verification. Steps to Reproduce Open the app and navigate to Phone Numbers. Ensure a custom provider is selected (not Lead Connector). Locate an AU phone number that requires a regulatory bundle. Click Verify Bundle. Actual Result The Verify Bundle action does not work when the custom provider is selected. Expected Result Verify Bundle should work regardless of whether Lead Connector or a custom phone provider is selected. Workaround Change the provider to Lead Connector and save. Go to Phone Numbers and complete Verify Bundle. Change the provider back to the custom provider and save. Impact Blocks or delays regulatory bundle verification for AU numbers when using custom providers. Creates repetitive, error-prone manual steps for agencies managing multiple client accounts. Suggested Fix Decouple the Verify Bundle flow from the selected voice/telephony provider, or ensure the verification endpoint/route supports custom providers the same way it supports Lead Connector. Please see video for details https://share.zight.com/Z4uXvA1j

Trying to connect Claude with GoHighLevel sub account so that I can speak automations into existence, but it appears we only have the ability to toggle on "readonly" instead of "write". This would be a game changing feature and save people hundreds of hours during account setup and ongoing maintenance of sub accounts! I'm getting tired of manually creating workflow automations over here! (the built in ai inside workflow automations told me he cannot do that yet)

Now it allows to select the plan immediately if there's no Trial period it deducts the payment. We want a simple schedule option to start the plan! Thanks

I hope you’re doing well. My name is Lucas, and I’m using GoHighLevel to manage conversations and leads from Facebook Ads campaigns that use the “Click to WhatsApp” (CTWA) format. I’ve noticed that when a WhatsApp message is received through these campaigns, the GoHighLevel platform does not relay (or expose) the ctwa_clid parameter in the webhook payload nor in the contact’s record. This parameter is essential for tracking and attributing conversions accurately, as it’s the unique identifier Facebook assigns to trace back the specific origin of the interaction. To provide more context, I’m using the webhook set up in the GoHighLevel developer platform (under the “API” section). However, the payload coming through to my webhook after the inbound message event does not include any referral details or parameters like ctwa_clid. I’d like to know: Is there an existing or upcoming feature that allows GoHighLevel to automatically capture the ctwa_clid when a user initiates a conversation from a Click-to-WhatsApp ad, and then pass it through to webhooks or other integration points? If not, is there any workaround or recommended approach (e.g., a landing page, custom fields, or advanced configuration) to help retrieve this parameter and store it within GoHighLevel? Are there any future plans to enhance the attribution and tracking of WhatsApp campaigns within GoHighLevel’s dashboard, allowing us to measure the performance of Facebook Ads more precisely and optimize our ad spend? Having native support or at least a method to receive the ctwa_clid in GoHighLevel would greatly improve our ability to track ROI on WhatsApp ad campaigns and automate our follow-up processes. Thank you very much for your assistance, and I look forward to your response. Best regards, Lucas Borthiry One South Media

I find it kind of crazy that inside Ai studio it doesn't even know that we're using go high level. It asks me to check with my CRM system and see if this works and other things similar to that. That's a pretty weird problem to have that it doesn't even know that it's inside of go high level.

It seems like most apps or sites have a dark mode toggle switch now a days and something I would have expected from highlevel by now. Bright white screens definetly create eye strain for us night owl workers and chrome extension tools just dont do the job correctly. Would love to see this asap! Thanks GHL Team!

Need: With AI becoming apart of search more and more I need a way to add the llms.txt to the root of the domain. Current: You cannot add txt file to root of domain. llms.txt is a proposed standard for helping LLMs access and interpret structured content from websites. You can read the full proposal on llmstext.org . In a nutshell, it’s a text file designed to tell LLMs where to find the good stuff: API documentation, return policies, product taxonomies, and other context-rich resources. The goal is to remove ambiguity by giving language models a curated map of high-value content, so they don’t have to guess what matters.

ISSUE Meta now requires event_source_url on Conversions API events for businesses whose dataset falls into a "restricted category" (Health & Wellness, Financial Services, etc.). Without it, Meta shows a warning in Events Manager: "Some Conversions API events will be blocked in 54 days" — and after that window, events stop being processed entirely. We investigated the native "Meta Conversion API" workflow action thoroughly and found two gaps that, together, make it impossible to fix this without leaving the GHL platform: GAP 1 — "Meta Conversion API" action has no event_source_url field Checked in both connection types (Integration / Ad Manager) and both event types (Funnel Event / Lead Event), with and without "Custom Mapping" enabled. Custom Mapping only supports FBCLID (Funnel Events), Facebook Lead ID (Lead Events) and IGSID (Instagram DM events) — no field for the landing page / source URL. Note: GHL DOES store this data per contact (Custom Values > Attribution > First/Latest > URL, e.g. {{contact.lastAttributionSource.url}}) — it's just not exposed as a mappable field in this action. GAP 2 — "Webhook" action can't build a valid Meta CAPI payload either As a workaround, we tried building a direct call to graph.facebook.com/{dataset_id}/events via the native "Webhook" action. This requires event_time as a Unix timestamp (integer, seconds since epoch) — a REQUIRED field for Meta CAPI. The "Right now" Custom Values category only offers human-readable date/time components (Second, Minute, Hour, Date in various formats) — there's no {{now.unix_timestamp}} or equivalent. Without it, no valid payload can be constructed. IMPACT Any GHL sub-account whose dataset gets categorized under a "restricted category" by Meta (very common for health/medical aesthetics, financial services, legal, etc.) will see their Conversions API events blocked, with no native fix available. This likely affects a large number of GHL users in these verticals, not just one account. REQUESTED FIXES Add event_source_url as a configurable field (static or Custom Value) in the "Meta Conversion API" action, for both Funnel Event and Lead Event types. Add a Custom Value such as {{now.unix_timestamp}} (current time, Unix epoch seconds), available in Webhook bodies and other workflow steps. Audit the "Meta Conversion API" action against Meta's full Server Event Parameters schema (action_source, event_source_url, event_time, etc.) to ensure compliance for restricted-category accounts. RELATED There's also an existing request for missing user_data parameters (em, ph, external_id, client_ip_address, etc.) — see "Facebook Conversion API additional parameters needs to be added". That's a related but separate gap (optimization/match-quality vs. our issue which is a hard compliance block). REFERENCE Meta dataset affected: 409806968859794 (category: Health & wellness providers / conditions and treatments) Confirmed via GHL AI Support that this is not currently documented as supported.

The customer reported that a contact's Documents tab contains media files (from June 17th) that belong to a different contact. Troubleshooting completed: Verified there are no Contact Merged events in the Activity tab. Checked the Audit Logs and found no merge activity. Confirmed the contact does not have secondary phone numbers or email addresses that could have caused contact consolidation. Reviewed the conversation thread and the June 17th media does not appear in the conversation history. The incorrect files are only visible under the contact's Documents tab. Customer is unsure whether the contact was ever merged, but all available logs indicate it was not. Expected behavior: Only media associated with the contact should appear under the contact's Documents tab. Actual behavior: Media belonging to another contact appears in this contact's Documents tab, causing confusion for staff. Customer requests: Determine how the incorrect media became associated with this contact. Advise how to prevent this from happening in the future. Remove the media that does not belong to this contact, if possible. Since there is no evidence of a contact merge, shared identifiers, or conversation crossover, this appears to be a possible backend issue with document/media association and would appreciate Engineering's investigation. HighLevel's documentation describes the Documents tab as storing files associated with the specific contact, so media from unrelated contacts should not appear there.

The functionality in v1 is great, but I can't assign tax to payments. Wish i could have both features in v2. Please add the look busy option to the new services!