App Marketplace

For healthcare/Medicare users, we need the ability to use a unique identifier such as Insurance/Member ID # or DOB instead of relying primarily on phone number or email for duplicate detection. Many senior patients—especially spouses—share the same landline phone number and/or email address, but they are two separate patients who each need their own contact record, appointments, workflows, notes, and communications. I just spent three days manually identifying and fixing duplicate records and adding patients who were missing from the contact database because of this issue. When spouses share contact information, the current duplicate logic can create significant data-management problems and make it difficult to ensure every patient has an individual record. Request: Allow a configurable custom field, such as Insurance/Member ID #, to be designated as the unique contact identifier or primary duplicate-matching field, with DOB available as an additional matching field. For organizations managing hundreds or thousands of Medicare patients, this would eliminate substantial manual cleanup and make GHL much more practical for healthcare use.

We often use VAs to assist with our marketplace app submissions or development. Currently the Marketplace app developer portal is an "all or nothing" situation. We need to be able to limit what apps team members get access to and a more granular set of permissions for what they can and cannot do once they have access.

We are doing marketing in Nepal and huge potential but due to the missing of payment gateway it is being difficult to execute. We request to integrate these gateway.

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

Summary Enable Marketplace Apps to securely share the authenticated SSO/session token with their own trusted Custom Menu Link iframe. This would allow developers to build seamless multi-page applications while preserving the existing security model. Problem Currently, window.exposeSessionDetails() is intended to provide an encrypted user context that can be sent to the application's backend for server-side validation. However, many Marketplace Apps consist of multiple entry points, such as: Marketplace App pages Custom Menu Links Embedded iFrames Additional application modules These components often belong to the same application and backend, but there is no supported mechanism to securely pass the authenticated session between them. As a result, developers must implement custom authentication flows, require users to log in again, or expose unnecessary identifiers to establish a session. Proposed Solution Allow Marketplace Apps to securely pass the encrypted SSO/session payload (or a short-lived signed token) to a trusted Custom Menu Link iframe that belongs to the same Marketplace App. The flow would be: The Marketplace App obtains the encrypted session payload using window.exposeSessionDetails(). The payload is securely forwarded to the application's backend for validation. After successful validation, the backend issues a short-lived application session or signed token. The validated session can then be securely shared with the application's Custom Menu Link iframe. The iframe uses this token to authenticate with the same backend without requiring the user to log in again. Security Considerations Only allow token sharing between components registered under the same Marketplace App. Validate the destination origin against the app's registered domains. Use short-lived, signed, single-use tokens. Require all validation to occur on the backend. Prevent token sharing with third-party or unregistered domains. Benefits Provides a seamless SSO experience across Marketplace App pages and Custom Menu Links. Eliminates duplicate authentication flows and repeated logins. Reduces the need to transmit company IDs, user IDs, or other identifiers solely for authentication. Encourages developers to follow secure, backend-validated authentication patterns. Enables richer, multi-page Marketplace applications while maintaining platform security. Example Use Cases Opening a full-screen dashboard from a Marketplace App. Launching an advanced admin portal from a Custom Menu Link. Sharing authentication across multiple application modules. Supporting secure embedded experiences without requiring additional user authentication. Building enterprise applications that span multiple trusted interfaces while maintaining a single authenticated session.

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, 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.

The current endpoint (/marketplace/billing/charges/has-funds) only returns a boolean for whether a wallet has any funds — it doesn't check against a specific charge amount. This breaks pre-flight cost checks for marketplace apps that incur variable, usage-based costs before billing the end user. For example, our app enriches contacts with email and phone data. If a user requests enrichment for 50 contacts, we incur a cost from our enrichment provider for every successful (positive) result — we only know the actual charge amount after the API call completes, since we're billed per successful retrieval, not per request. That means we can't charge the exact final cost to the wallet ahead of time. What we can do is calculate the maximum possible charge upfront (e.g. 50 contacts × per-contact rate, assuming a 100% success rate) and confirm the wallet can cover that worst-case amount before running the job — otherwise we risk incurring costs we can't recover from the end user. Requested change: Add a cost (or amount) query parameter to the endpoint so it checks whether the wallet balance can cover that specific charge, e.g.: GET /marketplace/billing/charges/has-funds?cost=6.35 Response: same boolean as today (true/false), but evaluated against the given cost rather than just checking for a non-zero balance. This lets apps pass in a worst-case/estimated cost and confirm funds are sufficient before incurring their own upstream costs on batch operations.

We want additional places for installable SSO secure custom pages that also have contact context. Example is the contacts panel and opportunities tab. This is like zoho and salesforce widgets. We need this to compete with these other CRMs.