Alternate Runtimes for G Suite Add-ons is coming soon. Learn more.

Publishing requirements

Before add-ons can be published publicly, they must be submitted to Google for add-on review. This process ensures that the add-ons available in the G Suite Marketplace meet quality and user protection guidelines.

Use the checklist below to make sure that your add-on passes the add-on review process. If you are publishing your add-on privately, you can still use this checklist to ensure your add-on provides a good user experience.

General requirements

Make sure your add-on meets the following general requirements before attempting to publish:

  • Completeness. The add-on must be fully functional. It can't be a “work in progress.”

  • Testing. The script has been tested with multiple active users as an unpublished add-on.

  • Naming. The script's project name is the same as the name intended for publication (the script name appears in the authorization dialog).

  • Style. Follow the recommendations in the add-on style guide.

  • Collaborators. If you are collaborating with others to build and maintain this add-on, be sure to configure your project collaborator access settings.

Technical requirements

Make sure your add-on meets the following technical requirements before attempting to publish:

  • Standard Cloud Platform (GCP) project. The add-on must use a standard GCP project. If the add-on is using a default GCP project, switch to a standard GCP project. All collaborators working on the add-on should have access to the standard GCP project.

  • Manifest. The add-on script project must include a well-defined manifest.

  • Libraries. The add-on does not use libraries unnecessarily, which can cause the add-on to run slowly in some cases.

  • Error handling. The add-on script has error-handling and shows relevant error messages to the user.

  • Hosted images. All users of the add-on can access any hosted image used in your add-on or its OAuth consent screen.

  • Versioned deployment. The add-on has a versioned deployment to be used for publication. Do not use head deployments for published add-ons. When you update your add-on, create a new script project version and edit the versioned deployment to use that version number.

  • Homepage and contextual trigger functions. If your add-on defines any contextual triggers or homepage triggers in its manifest, the add-on must implement the corresponding trigger functions.

  • Universal actions. Any universal actions used in your add-on script must specified in the manifest and implemented.

  • OAuth flow. If your add-on connects to non-Google services using OAuth, ensure it handles the OAuth authorization flow correctly.

User data protection requirements

The following requirements help to ensure that user data is protected while they use your add-on. Any add-on that fails to sufficiently protect user information cannot pass review for publication.

  • Scopes. You must set explicit scopes in the add-on manifest, choosing the narrowest scopes possible. Never have the add-on ask the user for more permissions than it actually needs. See Scopes for lists of scopes often used with G Suite add-ons extending different host applications.

  • UrlFetch whitelist. If the add-on script uses UrlFetch to retrieve data, you must whitelist the URLs it accesses using the urlFetchWhitelist manifest field. Restrict the URLs the add-on fetches to the following:

    • Legitimate third-party APIs,
    • Sets of private endpoints you control, and
    • Authorization endpoints that enable OAuth flows.
  • Open link whitelist. If your add-on script makes use of OpenLink actions, you must whitelist the URLs it opens using the addOns.common.openLinkUrlPrefixes field in the add-on manifest. This whitelist restricts what URLs the add-on can open. If your script code opens URLs that aren't whitelisted, you can't create or edit versioned deployments of your add-on. If your add-on functionality demands it, you can use a single * character as wildcard to match all links in the whitelist.

  • File access changes. If your add-on needs to update the access control list (ACL) of a G Suite or third-party file, it must inform the user it is doing so. ACL changes can't be handled silently in the background. For example, an add-on can't silently add email recipients to the set of accounts that can view a Dropbox file. Instead, the add-on should inform the user about the ACL change the add-on wishes to make and ask the user to confirm the change. Add-ons that don't inform users of such changes can't pass add-on review.

Marketplace listing asset requirements

In order to build your add-on's listing in the G Suite Marketplace, you must provide certain image, text, and URL assets for your add-on.

Before beginning the publication process, compile all the assets needed for Marketplace listings.

If desired, you can update the add-on assets after publication by editing the listing.