App Marketplace

In our Apps, we need to be able to archive/delete old conversation providers without having to create a brand new application.

I have a built a website and community area with Multiple Stand Alone Courses each with multiple video lessons. Some of my curses have 35 plus video tutorial lessons in which makes them large courses. When I list these courses with all the video lessons within a membership subscription plan they are all listed out in one long single column list. If I were to lets say make 30 courses each course with an average of 20 video lessons that's going to be a column 600 thumbnails long ! It's going to be a crazy long list to go through to find the course you want to do and with each passing month it's going to get an even bigger list. This is insane. Yet I am told there is no alternative way of doing it ! If the product or courses within a membership were listed out as an online shop page so you have the course thumbnail with some key course facts and as you clicked on the thumbnail it opened to a more comprehensive view showing all the video lessons within the course for you to click on and watch that would work. But one long list 600 thumbnails long does not work and is madness. Please contact me to discuss this as I really cant move forward with my website and online school business unless this is resolved.

Hi there, I would like to ask the GHL Devs to enable Marketplace App Developers to embed SVG icons into our Custom Page Links through custom html when selecting for an icon in the Custom Page (Custom Menu Selection) I hope people can upvote this, it really gives some branding for our app

Currently, Marketplace Apps are limited to a single Custom Menu object that lands in one of three places: Subaccount Only Agency Only Agency & Subaccount In our use cases, we would prefer to have separate custom menu objects. For example, our application has a client facing tool and an admin/agency tool. Our application already has the ability to distinguish which is being used - so we're taking advantage of showing each user (agency vs subaccount) the correct information, but we're limited in the naming convention of the Custom Menu object to be the same for both (even though they're doing drastically different things). Here's a simple use case: Marketplace App: SuperAgency Newsletter Magic Creation Extravaganza Purpose: Allows Agency to generate niche specific newsletters to their subaccounts Subaccount view: displays a dashboard showing the latest newsletters Agency view: displays the newsletter creation and selection tools as well as subaccount user/config menus Ideally, the subaccount should see "Newsletters" in their menu, while the agency should see the app name. This protects the Whitelabel through to the subaccount, while allowing the agency to easily identify the app/tool that they've installed. In this use case, our marketplace app would create two custom menu objects ("Newsletters" that displays only in the subaccount & "SuperAgency" that only displays in the agency account). This same functionality could be used to create multiple custom menu items per app (for those apps that handle many different functions) as well as gating each agency/subaccount entry point to a specific menu link (each custom menu object having their own url).

FOR SaaS Models: It's gonna be a key feature for the activity and access to the community from any mobile device and it's going to for sure boost the time spent and the engagement into the community and it will for sure drive more revenue that way = happy GHL customers!

Currently, developers have to set up external hosting, servers, and databases (AWS, Firebase, Vercel, etc.) to power their custom GoHighLevel apps. This creates unnecessary friction, cost, and complexity—especially for small development teams and white-labeled SaaS owners who want to build native-style integrations directly within the GoHighLevel ecosystem. Feature Request: Enable developers to host both their frontend apps and backend services natively inside GoHighLevel’s infrastructure — just like how GHL currently handles snapshots, funnels, automations, etc. This could be done through: A native “App Hosting” environment in the Developer Portal. Built-in database and API hosting capabilities (e.g., access to a GHL-managed Firestore-like or Postgres-like database). Serverless function support for backend logic (similar to Firebase Functions or AWS Lambda). Secure GHL API integrations so hosted apps can directly interact with CRM data, contacts, workflows, and automations. Why This Matters: ⚡ Speed: No need to manage deployment pipelines or servers. 💰 Cost-Effective: Eliminates third-party hosting expenses for small developers. 🔒 Security & Compliance: All data stays within GoHighLevel’s infrastructure — simplifying compliance and user data handling. 🧱 Ecosystem Growth: Makes it easier for developers to innovate and release new apps faster, enriching the GHL marketplace. ♻️ True All-in-One Platform: Extends GHL beyond marketing automation into a full no-code/low-code app platform. Summary: Let’s empower developers to build, host, and scale apps 100% natively on GHL, removing the need for any external servers or databases. This would position GoHighLevel as not just a marketing platform — but a true all-in-one SaaS creation ecosystem.

For People who dont have Stripe (Stripe has paused it's operations in India) Lemon Squeezy is a great alternative Plus it has been recently acquired by Stripe So it would be helpful if we can integrate it

We have an app in the marketplace which we allow agencies to white label and grey label but as we provide custom actions in the workflow the name of our custom action group is always taken as the marketplace app name Therefore, clients can always see the name of our app completely breaking the white label efforts that we put We should have the option to create a grey label name for a custom actions instead of it automatically pulling the marketplace app name

The App Marketplace search function looks for the app by name. But our users (and me) don't care about the name of the app. We care about the function of the app. How do we know we have found all valid options and how do we do due diligence to find the best solution for our situation? https://us06web.zoom.us/clips/share/xofdMR_kvt3RScjwe3Gl1OfetO_DCYIoh3Uh6boFll4YewNodbHkgIVSVV1URPYjHOU6ZLZ8SvkhcADwj1H1m4PN.drmeHYxbSaMwnRkk