Prove Marketplace eligibility before submission.
HubSpot Marketplace Listing Checklist 2026
Do not start with listing copy. First prove every current eligibility gate, then complete the seven listing tabs, run validation, resolve every error, and only then submit one app for review.
Last source check: 2026-08-29
Citation Summary
Use this page as an unofficial, source-linked planning reference for prove marketplace eligibility before submission. The key takeaway is: Do not start with listing copy. First prove every current eligibility gate, then complete the seven listing tabs, run validation, resolve every error, and only then submit one app for review.
Suggested citation: Projects App Guide, "HubSpot Marketplace Listing Checklist 2026," last source check 2026-08-29, https://projectsappguide.com/hubspot-marketplace-listing-checklist-2026
Answer Snapshot
- Short Answer
- A Marketplace app is not submission-ready until it clears HubSpot's minimum requirements—including OAuth, one matching public app ID, at least three active unique unaffiliated production installs with activity in the past 30 days, least-privilege scopes, policy gates, supported platform version, and any app-type-specific restrictions—plus complete listing validation.
- Applies To
- Teams preparing a HubSpot public or Marketplace app for review or client handoff.
- Verify
- Mark every eligibility item PASS/FAIL/UNKNOWN with dated evidence, then use Review info → Run validation and retain the resulting error-free state before submission.
- Boundary
- `distribution: marketplace`, a valid project, or an error-free listing form does not guarantee HubSpot approval.
Independent educational guide. Not affiliated with, endorsed by, or sponsored by HubSpot. Verify critical commands and platform behavior against official HubSpot documentation before deploying.
Gate 0: prove eligibility before writing copy
Use a three-state gate: PASS requires dated evidence, FAIL blocks submission, and UNKNOWN blocks this checklist's readiness decision until evidence is collected. UNKNOWN-as-stop is this guide's conservative process rule, not an additional HubSpot policy.
Prove the app is directly accessible, unique, and scoped to one use case; API calls use the same public app ID and OAuth client ID as the listing; OAuth is the sole authorization method; and at least three unique, active installs exist in unaffiliated production accounts. HubSpot defines activity as successful OAuth-authenticated API calls or qualifying signed requests during the past 30 days—not a test-account install count or an unverified dashboard total.
Also prove least-privilege scopes, Technology Partner Program Agreement acceptance, restricted-industry compliance, absence of classic CRM cards, and use of a currently supported developer-platform version. If the app is an AI connector, separately prove user-level permissions and that it is built with HubSpot's MCP Server. Any failed conditional gate is a product/architecture task, not a copy-edit task.
Gate 1: build a reviewable evidence packet
Make the listing integration-specific, not generic product copy. Prepare a public setup guide specific to the HubSpot integration, a working install-button URL, live support resources, current Terms and Privacy URLs, a scope-to-shared-data matrix, accurate pricing that matches the website, at least one support method, test instructions, contacts, screenshots with alt text, and implemented-feature evidence.
Crawl every submitted URL without authentication and keep each URL within HubSpot's 250-character limit. HubSpot says its SEO tools crawl associated pages and recommends allowing the `HubSpot Crawler` user agent before submission. A 200 response alone is insufficient: the page must be public, functional, current, and semantically match the field it fills.
If the app includes UI-extension app cards, add the card-specific brand, icon, sensitive-data, scope-use, browser-extension, asset-hosting, performance, usability, and accessibility checks from the current requirements page. Do not let a generic Marketplace packet conceal feature-specific gates.
Gate 2: run the listing validator
HubSpot's current listing guide says the editor must be a Super admin. The wizard contains Listing info, App details, Pricing, App features, Support info, Testing info, and Review info. Complete each tab and make the displayed app, redirect/install URL, shared data, pricing, assets, support details, test steps, and contacts match the evidence packet.
On Review info, expand all errors and use each error link to return to the responsible tab. If `Validate & submit` is gray, check Super admin permission and missing-field counts in tab headings, fill the missing data, then click `Run validation`. Do not interpret a gray control as a transient UI problem and repeatedly retry it.
The pass condition is an error-free validation state captured with app/listing identity, reviewer, timestamp, and source-check date. Submission is a separate state-changing action and should require owner approval after the evidence packet is frozen.
Submission and recovery boundary
HubSpot says only one app can be submitted at a time; additional apps submitted while the first is being processed are automatically rejected. Queue apps instead of parallel-submitting them. The same requirements page states an initial review target of 10 business days and says the feedback process should take no more than 60 days from feedback, but neither is an approval guarantee.
Different states require different responses: Draft-only means required listing information is incomplete or inaccurate; validation errors route to the named field/tab; rejection or reviewer feedback requires a tracked remediation response; a live listing edit must be resubmitted. Do not collapse these into one generic 'Marketplace failed' state.
Do not promise instant rollback after submission or publication. HubSpot documents a review workflow for edits and says an unpublish request is processed by the Marketplace team within 10 business days. Preserve the last approved listing evidence, but do not represent it as a guaranteed restore button.
Execution Contract
Use this as a stage-gated runbook. Each action has a required observable result, verification artifact, failure route, and recovery boundary.
Prerequisites
- Eligibility ledger has PASS evidence for access, uniqueness/use-case, matching public app ID/client ID, OAuth-only auth, install threshold, scopes, terms, industry/functionality limits, platform version, and any AI-connector gate.
- At least three active unique installs are evidenced as unaffiliated production accounts with successful app activity in the past 30 days—not test accounts or raw lifetime installs.
- A Super admin owns the listing; a separate engineering owner owns OAuth/install/feature evidence and a content/legal owner owns public URLs and claims.
- All public URLs, setup docs, install flow, shared-data table, pricing, support, privacy, terms, assets, and reviewer test instructions are complete and current.
Actions and acceptance evidence
Step 1
In Development → App Listings, choose `Create listing` and select the eligible app.
- Expected
- The intended app is selectable and the primary listing language can be chosen.
- Verify
- Match app name, public app ID/client ID, distribution/auth configuration, owner, and listing language to the eligibility ledger.
- On failure
- If Create listing is unavailable or the app is absent, check Super admin access, whether a listing already exists, and whether all existing apps already have listings before changing code.
- Recovery boundary
- Do not create a replacement app to bypass uniqueness, access, or listing-state constraints.
Step 2
Complete all seven tabs: Listing info, App details, Pricing, App features, Support info, Testing info, and Review info.
- Expected
- Required fields are populated with integration-specific, internally consistent evidence and live URLs.
- Verify
- Cross-check install URL, scopes/shared data, pricing, support/privacy/terms, setup guide, screenshots/alt text, test instructions, and contacts against the frozen packet.
- On failure
- Route each mismatch to its named owner; do not soften a claim or widen a scope merely to make fields appear complete.
- Recovery boundary
- Saving a draft is not submission, eligibility, approval, or publication.
Step 3
On Review info, expand all errors and click `Run validation` after fixing every required field.
- Expected
- No unresolved listing errors remain and the submission control is available to the authorized owner.
- Verify
- Capture the error-free validation state, app/listing identity, reviewer, timestamp, and current-source check date.
- On failure
- Use the error name to return to the responsible tab; if the button is gray, check Super admin permission and missing-field counters before retrying.
- Recovery boundary
- An error-free form still does not prove the external URLs are semantically correct, the app works, or HubSpot will approve it.
Step 4
After owner sign-off, submit one app for review and log all HubSpot feedback.
- Expected
- The submission enters HubSpot's review workflow and the team has one remediation queue tied to the submitted evidence version.
- Verify
- Record submission timestamp, submitted app/listing identity, source commit/evidence version, owner, and subsequent review status or email.
- On failure
- Classify the outcome as draft-only, validation error, automatic rejection from parallel submission, reviewer feedback, or rejection; follow the matching route instead of resubmitting blindly.
- Recovery boundary
- Approval is discretionary; editing a live listing requires review, and unpublishing is a processed request rather than an instant rollback.
Failure / Error Router
| Observed symptom | Route next | Stop condition |
|---|---|---|
| Fewer than three qualifying active installs or install evidence is ambiguous. | Reconcile unique unaffiliated production accounts and successful qualifying activity in the past 30 days; exclude test accounts, affiliated accounts, duplicates, and inactive installs. | Stop submission until three qualifying installs are evidenced; never manufacture activity or count test installs. |
| App uses static auth, another app ID/client ID, classic CRM cards, or an unsupported platform version. | Treat as an architecture hard block: correct OAuth/app identity, modernize cards, or upgrade the platform through the applicable official workflow before listing work resumes. | Stop if the proposed fix changes app identity, existing installs, scopes, or production behavior without a reviewed migration plan. |
| AI connector lacks user-level permissions or HubSpot MCP Server architecture. | Route to product/security architecture and the current HubSpot AI-connector requirement; listing copy cannot remediate it. | Stop submission until the conditional AI-connector gate is either proven not applicable or satisfied. |
| Public setup, install, support, terms, privacy, or pricing URL fails review/crawl. | Test unauthenticated access, redirects, freshness, semantic field match, URL length, robots/WAF behavior, and `HubSpot Crawler` allowlisting; retest the exact submitted URL. | Stop while any required page is private, stale, broken, misleading, or accessible only after sign-in. |
| Shared-data table and OAuth scopes disagree. | Map every object scope to data direction and implemented behavior; remove unused scopes or correct the listing and product behavior together. | Stop before describing read/write data as one-way or requesting scopes the app does not use. |
| `Validate & submit` is gray or Review info lists errors. | Verify Super admin permission, inspect missed-field counts in all seven tabs, expand all errors, open each error, correct it, and rerun `Run validation`. | Stop submission until the validator is error-free and the evidence packet still matches the edited fields. |
| Submission is automatically rejected while another app is under review. | Place the app in an internal queue and wait for the active review to finish; do not create duplicate apps or repeatedly resubmit. | Stop until the one-app-at-a-time constraint is clear and an owner schedules the next submission. |
Checklist
- Access, uniqueness, and one-use-case gates marked PASS with evidence.
- Public app ID and OAuth client ID match the listing and API authorization path.
- OAuth is the sole authorization method; scopes are least-privilege and used.
- At least three qualifying active unique installs evidenced for the past 30 days.
- Terms, restricted-industry, classic-card, and supported-platform gates passed.
- AI-connector user-permission and HubSpot MCP Server gate passed or marked not applicable with rationale.
- Setup, install, support, Terms, Privacy, and pricing URLs are public, live, current, functional, and under 250 characters.
- Shared-data objects and direction match requested OAuth scopes and implemented behavior.
- Integration-specific copy, pricing, screenshots/alt text, feature descriptions, test steps, and contacts are complete.
- App-card-specific brand, sensitive-data, extension, asset, performance, usability, and accessibility gates checked when applicable.
- Super admin ownership confirmed and all seven tabs completed.
- Review info expanded; every error resolved; `Run validation` passes.
- Only one app is queued for HubSpot review at a time.
- Submission evidence version, timestamp, owner, and feedback route recorded.
Claim / Source Map
These are the main claims this page relies on. Re-open the linked official HubSpot source before production-affecting commands, uploads, submissions, or client delivery.
| Claim | Official source |
|---|---|
| Marketplace eligibility requires OAuth as the sole authorization method, the listing's public app ID/client ID, and at least three active unique installs in unaffiliated production accounts with successful activity in the past 30 days. | App Marketplace listing requirements |
| Other minimum gates include least-privilege scopes, terms and restricted-industry checks, no classic CRM cards, a supported developer-platform version, and special user-permission/MCP Server requirements for AI connectors. | App Marketplace listing requirements |
| The listing workflow requires Super admin permission; Review info exposes listing errors and `Run validation` before submission. | Listing your app |
| Incomplete or inaccurate critical listing information can leave a listing in Draft mode only, and linked pages must be live, public, functional, and crawlable. | App Marketplace listing requirements |
FAQ
What are the Marketplace eligibility hard stops before listing work?
Stop for any failed or unknown access, uniqueness/use-case, matching app ID/client ID, OAuth-only, three-active-install, least-scope, terms, restricted-industry/functionality, supported-platform, or applicable AI-connector gate. This guide treats UNKNOWN as not ready until evidence exists.
Do three developer test-account installs satisfy the install gate?
No. HubSpot defines qualifying active installs as unique production accounts unaffiliated with your organization that show successful qualifying app activity in the past 30 days.
What should I do when Validate & submit is grayed out?
Confirm the editor is a Super admin, inspect missing-field counts on every tab, expand all Review info errors, fix each linked field, and click Run validation again. Do not submit or create a replacement app until the cause is known.
Does error-free listing validation guarantee approval or provide instant rollback?
No. HubSpot manually reviews submissions and may reject or unpublish listings. Live listing edits require resubmission, and documented unpublish requests are processed rather than acting as an instant rollback switch.
Get the full Projects CLI Skill Pack
Includes the agent skill, command cheatsheet, checklist, CSV tracker, handoff template, and official source map.
Independent educational product. Gumroad checkout opens in a separate page; no official affiliation or guarantee is implied.