The GoHighLevel Snapshot Marketplace, Explained

The GoHighLevel Snapshot Marketplace is the storefront layer built on top of snapshots: a place inside Agency View, and separately at marketplace.gohighlevel.com, where agencies browse and buy pre-built pipeline, automation, funnel, and calendar templates, or list their own for other agencies to buy. It’s a different thing from building a private snapshot for your own sub-accounts, which we cover in detail in GoHighLevel Snapshots Explained. This guide is about the marketplace mechanics specifically: how listings get built and reviewed, how a purchase actually becomes a working sub-account, and what GoHighLevel does and doesn’t disclose about money changing hands, sourced against GoHighLevel’s own documentation rather than recycled agency blog copy.

What is actually inside the Snapshot Marketplace?

A snapshot listing in the Marketplace is a packaged, exportable copy of a sub-account’s configuration — pipelines, workflows, funnels, forms, calendars, tags, and custom fields — wrapped in an App Marketplace listing with its own name, logo, description, and pricing. Per GoHighLevel’s own Snapshots marketplace-module documentation, a listing requires an app name, distribution type (Agency or Sub-Account level), a logo and tagline, a company name and website, preview images or a demo video, support contact details, and a pricing configuration before it can be submitted for review.

That’s a materially heavier lift than exporting a private snapshot for internal use, which is a single share-link action inside your own account. The Marketplace layer exists specifically because a listing is public-facing: another agency is going to install this configuration sight-unseen into a live sub-account, so GoHighLevel requires the same kind of app-store metadata it requires of any third-party integration, not just a raw export link.

Browsing the marketplace works the way most agencies expect: filter by category, price, and rating, preview the description and screenshots, and either install a free listing directly or purchase a paid one. What’s less obvious from browsing alone is that a purchase and an installation are two separate actions, covered below, and that the review process a listing went through before it appeared in your search results has its own documented timeline and constraints.

How does an agency actually list a snapshot for sale?

Listing a snapshot for sale runs through GoHighLevel’s Developer Portal, not through a simple “make this snapshot public” toggle inside a sub-account. Per the marketplace documentation, the process runs in five stages: sign up at marketplace.gohighlevel.com and verify your email, create an app in the Developer Portal with its configuration details, fill in the app’s listing information (logo, description, company and support details), set the pricing structure, and generate the snapshot’s share link through the “Get Marketplace Share Link” action before submitting the whole listing for review.

The review itself is where most sellers underestimate the process. GoHighLevel’s documentation states plainly that “the HighLevel team will review your app for white-label compatibility within 7-10 days.” That review isn’t a rubber stamp — it’s specifically checking that the snapshot and its listing don’t leak unbranded GoHighLevel references into what’s supposed to be a clean, resellable template. A rejected submission gets feedback and can be resubmitted, but there’s no published fast-track for a resubmission, so a seller who gets bounced on a fixable issue (a missed support field, an unbranded funnel page inside the snapshot itself) should expect the review clock to effectively restart.

Two constraints in the current documentation are worth flagging because they change how an agency should scope its snapshot business before building anything: only one snapshot is allowed per app listing, and published listings can’t be modified after they go live. In practice that means a seller planning multiple snapshot products — a “starter” tier and a “pro” tier, for instance — needs separate app listings for each, not one listing with variants, and any meaningful update to a published snapshot’s contents likely means a new listing rather than an edit to the existing one. Several third-party guides describe the buying side of the marketplace in detail and skip this seller-side constraint entirely, which is exactly the kind of gap that costs an agency real time once it tries to actually list something.

Free, freemium, or paid — what pricing models does the marketplace actually support?

GoHighLevel’s documentation confirms three pricing structures for a marketplace listing: free (no cost to the buyer), freemium (free with paid premium features), and paid, which itself splits into one-time, monthly, or yearly subscription billing. That’s a meaningfully wider set of options than most third-party recap articles mention, which tend to describe snapshots as either “free” or “paid” without the freemium tier or the recurring-billing option.

What the same documentation does not do is publish a revenue-share percentage or a seller fee. That’s a genuine gap, not an oversight in this guide — GoHighLevel’s own marketplace-module docs describe how to set a price, not what cut the platform keeps from a sale. Any article stating a specific percentage GoHighLevel takes from snapshot sales is not quoting documented policy; it’s repeating an unsourced figure that’s likely been copied from post to post across the same set of agency-run sites that dominate this search term. If margin certainty matters for a seller’s pricing decision, the accurate answer is to test a listing at a specific price point and compare payout against the sale price directly, rather than trust a percentage figure circulating on forums or in other guides.

There’s a second, distinct monetization path worth separating from a standalone marketplace sale: attaching a Marketplace snapshot directly to a SaaS Configurator plan. Per GoHighLevel’s Selling Marketplace Snapshots with SaaS Plans documentation (modified 11 December 2024), an agency can open a SaaS plan’s Features tab in the SaaS Configurator, select “Add Snapshot,” choose “Marketplace” to browse available snapshots, and attach one to that plan. Once attached, the snapshot installs automatically the moment a client purchases that plan through sub-account creation — no separate marketplace transaction, no manual import step. The same documentation notes attached snapshots can be automatically removed if the plan’s distribution type changes, the underlying app is uninstalled, a payment issue occurs, or the snapshot’s status is disabled — worth knowing before building a client-facing plan around a specific attached snapshot as a selling point, since that dependency can silently break.

What does a snapshot actually carry into a sub-account — and what doesn’t it?

This is the question most buyers get wrong, and it matters just as much for a marketplace purchase as for a snapshot you build yourself. Per GoHighLevel’s Snapshots Overview documentation (modified 7 May 2026), a snapshot transfers configuration and selected reusable assets: workflows, triggers, voice agents and conversation AI settings, funnels, forms, campaigns, email templates, blogs, calendars and calendar resources, custom fields, pipelines, tags, dashboards and custom reports, documents, WordPress sites, WhatsApp templates, and membership structures.

What it explicitly does not transfer is live account data: contacts, appointments, conversations and conversation history, messages, reputation data, active integrations, Stripe connections, WordPress plugin licenses that require re-authentication, private dashboards, and contact-to-contact associations. That distinction is why loading a purchased snapshot into a sub-account with existing clients in it is a safe, additive action rather than something that risks overwriting a client’s contact list — the snapshot has no mechanism to touch that data in the first place.

The practical implication for a marketplace buyer: a snapshot marketed as a complete “done for you” business system is still, mechanically, a configuration template. Integrations, Stripe accounts, and any real client data still have to be connected and populated after import, on every sub-account the snapshot gets loaded into. A seller’s marketing copy describing “plug and play” setup is describing the automation and pipeline layer, not the connections layer underneath it — worth clarifying with a buyer before they assume a purchased snapshot means zero setup work.

How does buying and importing a marketplace snapshot actually work?

Purchasing a snapshot from the marketplace and getting it live in a sub-account are two distinct steps, and conflating them is a common source of confusion for agencies new to the marketplace. A purchase — free or paid — adds the snapshot to the buying agency’s list of Imported Snapshots, found under Settings > Account Snapshot at the agency level. It does not automatically appear inside any specific sub-account.

Getting it into a sub-account follows the same manual process GoHighLevel documents for any snapshot, marketplace-sourced or self-built. Per GoHighLevel’s Load Snapshots into an Existing Sub-Account documentation, the steps run from Sub-Accounts in the agency menu: open the three-dot menu beside a specific sub-account’s “Switch to Sub-account” button, select “Manage Client,” then “Actions,” then “Load Snapshot.” From there, the buyer picks the snapshot from the pre-imported list, selects or skips individual assets rather than importing everything wholesale, checks for and resolves any naming conflicts, and types “Confirm” to start the load.

Two details worth confirming before a client demo: the asset-selection step means a buyer can deliberately skip parts of a snapshot they don’t want (an unwanted funnel, a workflow that conflicts with something already built), and the conflict check exists specifically because loading a second snapshot into a sub-account that already has pipelines or tags with matching names can silently merge or duplicate configuration rather than cleanly overwrite it. Reviewing the conflict list before confirming, rather than clicking through it, is the difference between a clean import and a sub-account with two versions of the same pipeline stage.

Where the Snapshot Marketplace differs from building your own

The Marketplace is one path to a working snapshot, not the only one, and it’s worth being direct about the tradeoff. A self-built snapshot, covered in full in GoHighLevel Snapshots Explained, is exported from a sub-account you already configured and tested, so it matches your actual sales process by construction. A marketplace snapshot is built by someone else, for a use case that may or may not match yours closely enough to skip the adaptation work — pipeline stages, tags, and triggers still need review against the buyer’s real workflow before go-live, the same caution that applies to any pre-built template regardless of where it came from.

Where the marketplace earns its place is speed and coverage for use cases an agency hasn’t built internally yet — a vertical it’s new to, a workflow pattern (review-request automation, a specific booking flow) that’s already been built and tested by someone else. Treating a purchased snapshot as a strong first draft rather than a finished deliverable is the same guidance that applies to any template, and it’s worth setting that expectation with a client before quoting a marketplace-sourced build as if it required zero configuration work.

What agencies get wrong when scoping a snapshot business

A few patterns show up repeatedly in how agencies approach the marketplace, on both the buying and selling side:

• Assuming a purchase is a finished install. As covered above, a marketplace purchase and a live sub-account installation are separate steps — the second one still has to happen manually, per sub-account, every time.
• Planning a multi-tier snapshot product as one listing. The one-snapshot-per-app limit means a “starter” and “pro” version need two separate Developer Portal listings, not one listing with variants — worth knowing before pricing and naming a product line.
• Quoting a specific GoHighLevel revenue-share percentage to a client or partner. GoHighLevel’s own documentation doesn’t publish one. Repeating a number from another blog post as if it were confirmed policy is a factual claim this guide won’t make and one worth avoiding in a client conversation too.
• Treating a marketplace snapshot as carrying real client data. It never does — contacts, conversations, and integration connections are excluded by design, on every snapshot, marketplace or self-built.
• Skipping the white-label review requirement when planning a launch timeline. The 7-10 day review is documented, and a rejected submission effectively resets that clock, so a snapshot product launch tied to a specific date needs buffer the same way an app-store submission does.

Building and pricing a snapshot product correctly — the Developer Portal listing, SaaS Configurator attachment, and the underlying sub-account architecture it all depends on — is enough moving parts that some agencies bring in outside help rather than work through the documentation gaps solo the first time. Either route, the mechanics in this guide are what’s actually being configured behind the scenes.

How the Snapshot Marketplace sits inside the broader App Marketplace

The Snapshot Marketplace isn’t a standalone product — it’s one module inside GoHighLevel’s wider App Marketplace, which also lists third-party integrations, custom menu links, and full white-label apps built on the platform’s API. That matters for how a listing gets discovered: a buyer browsing for a snapshot is searching the same storefront as a buyer looking for a Zapier alternative or a review-request integration, filtered down by the Snapshots category rather than a separate destination. A seller building a listing should expect the same discovery mechanics — category placement, star ratings once reviews accumulate, and preview screenshots — that apply to any other Marketplace app, not a snapshot-specific ranking system.

That shared infrastructure also explains why the review process checks specifically for white-label compatibility rather than snapshot-specific criteria alone. GoHighLevel’s review team is running the same compatibility check it would run on any Marketplace submission: does the listing expose unbranded GoHighLevel references it shouldn’t, does the support and billing information match what’s required for any paid app, and does the distribution type (Agency-level or Sub-Account-level) match what the snapshot actually does once installed. A seller who’s only thought about the snapshot’s automation content, and not the listing’s white-label hygiene, is the most common source of a first-round rejection.

It’s also worth checking GoHighLevel’s own homepage and current plan pages before pricing a snapshot product, since Marketplace access and the SaaS Configurator features that let a snapshot attach to a plan both sit behind specific subscription tiers rather than being available on every account by default — the same plan-gating pattern this site has documented for white-label features applies here too, and it’s worth confirming against current account settings rather than assuming every tier includes full Marketplace selling access.

What the import documentation covers that most guides skip

GoHighLevel maintains a separate, more granular How to Import Snapshots article alongside the sub-account-specific loading steps covered above, and it’s worth reading both if a snapshot — marketplace-sourced or otherwise — is going into a brand-new sub-account rather than an existing one. The mechanics differ slightly: loading a snapshot during initial sub-account creation happens as part of the setup wizard, while loading one into an account that’s already live and has its own configuration runs through the Manage Client menu described earlier and forces the asset-selection and conflict-check steps, because there’s existing configuration it could collide with.

That distinction is easy to gloss over in a rushed onboarding, and it’s the source of a specific, avoidable mistake: an agency that treats every snapshot load as the “new sub-account” version skips the conflict check entirely when the target account isn’t actually new, and ends up with duplicated pipeline stages or a workflow that silently overwrote a client-specific trigger nobody remembered was there. Reading the sub-account’s history before choosing which import path applies, rather than assuming, is a five-minute step that avoids a much longer cleanup conversation with a client later.

A realistic way to evaluate a marketplace snapshot before buying

A short checklist worth running before paying for any marketplace snapshot: does the listing’s description specify which sub-account elements it includes (pipelines, workflows, funnels, calendars specifically, not just “everything”)? Is the seller’s support contact a real, monitored channel, or a generic email with no response history? Does the preview show actual screenshots of the built-out pipeline and workflow logic, or only marketing graphics? Is the pricing model (one-time versus recurring) clearly stated, and does it match what the checkout screen actually charges? And has anyone tested the snapshot on a throwaway sub-account before loading it into a live client account — the same caution GoHighLevel implicitly assumes by making asset selection and conflict resolution explicit steps in the import flow, rather than a single-click action.

None of these checks require contacting GoHighLevel support directly, and all of them are things a buyer can verify from the listing page and a test import before committing a client’s sub-account to an untested template. The agencies that get burned by a marketplace purchase are usually the ones that skipped the test-import step under the same kind of launch-week time pressure that causes app-store rejections and rushed white-label rollouts elsewhere on the platform.

Getting the marketplace layer right

The Snapshot Marketplace is straightforward in outline — browse, buy or list, import — but each layer has its own documented constraint most recap content skips: the 7-10 day white-label review, the one-snapshot-per-app limit, the split between a purchase and a live installation, and the honest absence of a published revenue-share figure. Buying from the marketplace still means treating what you bought as a first draft, not a finished sub-account, and selling on it means budgeting real time for the Developer Portal listing process and its review window, not assuming a snapshot goes live the same day it’s submitted.

If you’re scoping a snapshot product, a client rollout built on a marketplace template, or the underlying sub-account architecture the marketplace snapshots plug into, aibrevo’s GoHighLevel implementation services page covers what a properly scoped build includes, from sub-account structure through the SaaS Configurator and snapshot attachment work covered above.