An app marketplace listing guides onboarding. Shape it around the decisions a buyer and the person approving access must make before use. Set the listing boundary first, then connect the marketplace events, account flow, and setup material. Publishing multiple integrations in one listing can streamline installation and authorization.1 The consent screen lists every scope required by every integration in that listing.2 Check compatibility and scope impact before you submit, because changing the shape after launch creates work for users and for the team maintaining the integration.
Choose the listing shape
Use the smallest listing structure that gives users a clear installation path. If you have multiple integrations, decide whether they belong together before building the submission materials.
Decide which integrations a buyer should install and authorize together and whether they share a coherent setup path.
Web apps, Drive apps, and Docs, Sheets, Slides, and Forms add-ons can often be combined in one listing, subject to compatibility rules.3 Use the marketplace comparison table to determine which integrations can share a listing.4 Find the starting integration in the left-hand column, find the endpoint in the top row, and trace both lines to their intersection.5
A listing cannot contain more than one Google Workspace add-on.6 A single Google Workspace add-on can extend Gmail, Google Calendar, Google Chat, Google Drive, Google Docs, Google Sheets, Google Slides, and Google Meet.7 The compatibility option for Chat applies only to Chat apps built as Google Workspace add-ons. Other Chat apps must be listed separately.8
Record the scopes each integration needs before you submit. Identify who will approve those scopes, what the user sees, and whether the combined consent screen makes sense for the installation path.
Build the marketplace plumbing
The marketplace connection must work after purchase, during account creation, and when the subscription changes. Build and test those handoffs before treating the listing as ready.
For a Cloud Marketplace listing, the app backend must integrate with the specified Google APIs and services.9 Use Pub/Sub to receive marketplace notifications, including a notification when a user signs up.10 The Partner Engineer creates the Pub/Sub topic that the app must subscribe to.11
Use the Partner Procurement API to create customer accounts and link them to the marketplace purchase.12 Continue using that API when users change or cancel their subscription plans so the linked accounts stay current.13 If the pricing model is usage-based, integrate with Service Control to report usage information.14
Set up the marketplace integrations in the frontend.15 Provide a sign-up page for new customers who purchase through the marketplace.16 When a user visits that page, the marketplace sends a JSON Web Token containing the user account ID.17 Use that account ID to connect the product account with the user's Google Account and for Identity and Access Management.18
Provide a login page for customers.19 You can add single sign-on so customers sign in with their Google Accounts.20 When they use single sign-on, the marketplace sends a JSON Web Token with information for the app to verify.21
Track which event creates the customer account, which changes its entitlements, and what happens when the buyer reaches the sign-up page without an existing product account.
Before testing, verify that the Partner Engineer has enabled access to the Cloud Commerce Partner Procurement API.22 After that access is granted, no further API enablement is needed in the cloud console.23
Prepare the listing page
Write the page for the person deciding whether the integration fits and the technical team deciding whether it can be installed. A buyer should understand the connection, its requirements, and the first setup action without chasing your team.
The website listing page should be user friendly, engaging, and helpful to prospects and customers.24 Show your name with your partner's name or logo.25 Describe the partner's product and the value of the integration.26 Keep the description specific enough to answer what moves between the systems and what the user can do after setup.
Include system requirements and install instructions so prospects can pass the technical details to their technology and leadership teams.27 Give the sales team a listing URL it can paste into sales emails during the buying process.28
Add a how-to video for setup.29 A step-by-step setup video can reduce hand-holding from the customer-success team and speed adoption among existing customers.30 Include screenshots of the integration in action.31 Use them to show customers and prospects what the integration can do.32
A technical reviewer should be able to find the requirements, installation steps, and expected result on the page. An existing customer should be able to follow the setup without waiting for a meeting.
Submit through the partner route
Submission depends on the marketplace owner, so confirm that your product belongs in the directory you are using. Keep the partner program, app build, and listing submission in one tracked path.
For an ISV with an app, the App Marketplace is the software directory, while the Solutions Directory shows agencies that implement HubSpot.33 The route is to join the Technology Partner Program, build the app, and submit a Marketplace listing.34 Keep those routes separate when you plan distribution, because they represent different types of partner work.
Before submitting, walk through the listing as a new buyer. Confirm that the installation action reaches the right account flow, the permissions match the product experience, and the page gives the technical reviewer enough information to proceed.
Maintain the published listing
A published listing is part of the product's access path. Changes to its structure can create customer work, so review the effect on existing installs before moving an integration or adding new scopes.
Keep a record of the listing's integrations, scopes, account handoffs, and setup materials. When you change one of those pieces, test the path from installation through first use and update the page where the customer will encounter the change.
What not to do
- Do not combine integrations without checking for broader consent screens, scope verification, and user access effects.35
- Do not add an integration that requires additional scopes to an existing listing without planning for authorization in the Google Admin console. Administrators who installed the original app for their domain must authorize the additional scopes, or users in that domain are prompted individually.36
- Do not move an integration assuming existing users keep access. They might lose access and need to install the listing to which you moved the integration.37
- User counts and reviews do not carry over when an integration moves to another listing, so do not treat them as transferable.38