App Marketplace

Feature Request: Prospecting Premium Data Visible on Pipeline Cards Currently, Prospecting Premium report data (audit scores, findings, etc.) is stored in contact custom fields but is not visible on pipeline opportunity cards. Users have to leave the pipeline view and open each individual contact record to access this data. Requested improvement: Surface key Prospecting Premium report fields directly on the pipeline card so users can assess prospect quality without leaving the pipeline view. Use case: When working a list of prospects in the "Report Generated" stage, users need to quickly see audit results to prioritize who to reach out to — without clicking into each contact one by one.

We want to be able to install a custom nav bar icon that opens a popup iframe. This would use the current SSO feature to then give us context of the account they are in. If they are viewing a contact or opportunity then we would also get that added context. This helps apps add functionality where we can open our installed apps from anywhere in the highlevel software. So this is helpful for custom support chat widgets and a variety of use cases.

We want to be able to install custom dashboard widgets with marketplace apps. They would need secure SSO and context regarding the location or other configured filtering data like date ranges etc. The reason why is we have no way of securing access to data currently in the standard dashboard widget UI other than setting URL param tokens or other workarounds. In order to sell custom widgets we need them to be installable.

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.

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.

It would be useful to know how many views our app listings are getting to understand if we need to optimise our listing etc

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

Currently, when a message is sent through a Marketplace App such as CloseBot, the Message Details panel displays: "Marketplace App (Only visible to agency): CloseBot" This information is only visible to agency users and is hidden from subaccount users. Requested Enhancement Provide an option for agencies to allow subaccount users to see message attribution from Marketplace Apps (such as CloseBot) within Message Details. Potential implementation options: Agency-level toggle: "Allow subaccount users to view Marketplace App message attribution" User permission: "View Marketplace App message sources" Display a simplified label such as: Sent by CloseBot Sent by AI Assistant Sent by Marketplace App Use Case Many agencies deploy AI-powered conversation tools like CloseBot inside client accounts. When venue owners, sales teams, and staff review conversations, they often need to know: Whether a message was sent by a human team member or AI Which messages were generated by CloseBot Whether the AI handled a conversation correctly How AI performance compares to manual responses Whether a particular response requires follow-up or intervention Currently, only agency users can see this information, creating confusion for subaccount users who are actively managing conversations. Business Impact This enhancement would: Increase transparency between agencies and clients Improve AI adoption and trust Reduce support requests asking who sent a message Improve troubleshooting and quality assurance Help teams audit AI-driven conversations Make Marketplace App integrations more valuable for end users Example Current: Message Details Marketplace App (Only visible to agency): CloseBot Proposed: Message Details Sent By: CloseBot Marketplace App: CloseBot (or) Message Details AI Generated: Yes Source: CloseBot Why This Matters As agencies increasingly deploy AI solutions through the Marketplace, subaccount users need visibility into how conversations are being managed. Providing message attribution at the subaccount level would improve accountability, transparency, and user confidence while maintaining agency control through permissions.

We need a proper brandkit for highlevel and leadconnector logos to use within applications for integration purposes.