Note: We are still rolling out some features of G Suite Add-ons. You can start developing new G Suite add-ons, but may be unable to test them until the rollout is complete in early February 2020.

Manifests for G Suite add-ons

An Apps Script project uses a manifest file to configure certain details about the script and its operation. A manifest is a special JSON-formatted file that is hidden in your script project by default; in most cases, Apps Script automatically adjusts the manifest in response to actions you take in the Apps Script editor. For example, if you add a library to a script project, the relevant details of that library are added to the manifest behind the scenes for you. See Manifest structure for a list of properties an Apps Script project can define in its manifest.

Sometimes it is helpful or necessary to edit a manifest directly. For example, if you intend to publish an add-on you must configure your add-on's manifest to always use the narrowest scopes possible. See Setting explicit scopes for more details.

This documentation covers the details of configuring a manifest for a G Suite add-on.

Editing a manifest

The Apps Script editor hides manifest files by default in order to protect your Apps Script project settings. Follow these steps to make a hidden project manifest visible in the Apps Script editor:

  1. Open the script project in the Apps Script editor.
  2. Select View > Show project manifest.

The manifest file appears as a project file named appsscript.json. You can edit this file directly in the editor and save any changes you make. To hide the manifest file after you are finished, select View > Show project manifest again.

Manifest structure for G Suite Add-ons

G Suite add-ons use the Apps Script project manifest file to define several aspects of the add-on's appearance and behavior. G Suite add-on manifest properties are organized under the addOns section of manifest object structure.

The following manifest file example snippet shows the section of a manifest file that defines a G Suite add-on. The addOns.common section of the manifest defines the name, logo URL, colors, and other general, host-independent settings for the add-on. The manifest defines a common homepage, but also defines Calendar- and Drive-specific homepages (Gmail uses the default homepage here). The example also has settings to enable Calendar eventOpen and eventUpdated triggers, a Drive onItemsSelectedTrigger, a Gmail compose action, a Gmail contextual trigger, and two universal actions. The excerpt also gives examples of a manifest's oauthScopes and urlFetchWhitelist fields, which most add-on manifests must set.

The links in the example direct to the descriptions of that field in the Apps Script manifest reference documentation.

{
  ...
  "addOns": {
    "calendar": {
      "currentEventAccess": "READ",
      "eventOpenTrigger": {
        "runFunction": "onCalendarEventOpen"
      },
      "eventUpdateTrigger": {
        "runFunction": "onCalendarEventUpdate"
      },
      "homepageTrigger": {
        "runFunction": "onCalendarHomePageOpen",
        "enabled": true
      }
    },

    "common": {
      "homepageTrigger": {
        "runFunction": "onDefaultHomePageOpen",
        "enabled": true
      },
      "layoutProperties": {
        "primaryColor": "#ff392b",
        "secondaryColor": "#d68617"
      },
      "logoUrl": "https://ssl.gstatic.com/docs/script/images/logo/script-64.png",
      "name": "Demo G Suite Add-on",
      "openLinkUrlPrefixes": [
        "https://mail.google.com/",
        "https://script.google.com/a/google.com/d/",
        "https://drive.google.com/a/google.com/file/d/",
        "https://en.wikipedia.org/wiki/",
        "https://www.example.com/"
      ],
      "universalActions": [{
        "text": "Open settings",
        "runFunction": "getSettingsCard"
       }, {
        "text": "Open help page",
        "openLink": "https://www.example.com/help"
      }],
      "useLocaleFromApp": true
    },

    "drive": {
      "homepageTrigger": {
        "runFunction": "onDriveHomePageOpen",
        "enabled": true
      },
      "onItemsSelectedTrigger": {
        "runFunction": "onDriveItemsSelected"
      }
    },

    "gmail": {
      "composeTrigger": {
        "authorizationCheckFunction": "get3PAuthorizationUrls",
        "selectActions": [
          {
            "text": "Add images to email",
            "runFunction": "getInsertImageComposeCards"
          }
        ],
        "draftAccess": "METADATA"
      },
      "contextualTriggers": [
        {
          "unconditional": {},
          "onTriggerFunction": "onGmailMessageOpen"
        }
      ]
    }
  },

  "oauthScopes": [
    "https://www.googleapis.com/auth/calendar.addons.current.event.read",
    "https://www.googleapis.com/auth/drive.addons.metadata.readonly",
    "https://www.googleapis.com/auth/gmail.addons.current.action.compose",
    "https://www.googleapis.com/auth/gmail.addons.current.message.metadata",
    "https://www.googleapis.com/auth/userinfo.email",
    "https://www.googleapis.com/auth/script.locale",
    ...
  ],
  "urlFetchWhitelist": [
    "https://www.example.com/myendpoint/",
    ...
  ],
  ...
}

Whitelisting URLs

Sometimes you may want your G Suite add-on to open a URL in response to a user action. Other times you may want your add-on to retrieve information from an external location using the Apps Script UrlFetch service. In both cases you must whitelist the URLs you open or fetch from in the project manifest.

Whitelisting is the process where you designate specific URLs that are pre-approved for access by your add-on. This requirement helps protect user data; add-ons can't access URLs that have not been whitelisted.

You can whitelist a URL for opening by adding it or a matching prefix to the manifest addOns.common.openLinkUrlPrefixes field. Similarly, you can whitelist a URL for fetching by adding it or a matching prefix to the manifest addOns.urlFetchWhitelist field.

The prefixes you add to the manifest must satisfy the following requirements:

  • Each prefix must be a valid URL.
  • Each prefix must use https://, not http://.
  • Each prefix must have a full domain.
  • Each prefix must have a non-empty path. For example, https://www.google.com/ is valid but https://www.google.com is not.
  • You can use wildcards to match URL subdomain prefixes.
  • A single * wildcard can be used in the addOns.common.openLinkUrlPrefixes field to match all links, but this is not recommended as it can expose a user's data to risk and can prolong the add-on review process. Only use a wildcard if your add-on functionality requires it.

When determining if a URL matches a whitelisted prefix, the following rules apply:

  • Path matching is case-sensitive.
  • If the prefix is identical to the URL, it is a match.
  • If the URL is the same or a child of the prefix, it is a match.

For example, the prefix https://example.com/foo matches the following URLs:

  • https://example.com/foo
  • https://example.com/foo/
  • https://example.com/foo/bar
  • https://example.com/foo?bar
  • https://example.com/foo#bar

Using wildcards

You can use a single wildcard character (*) to match a subdomain for both the addOns.urlFetchWhitelist and addOns.common.openLinkUrlPrefixes fields. You can't use more than one wildcard to match multiple subdomains, and the wildcard must represent the leading prefix of the URL.

For example, the prefix https://*.example.com/foo matches the following URLs:

  • https://subdomain.example.com/foo
  • https://any.number.of.subdomains.example.com/foo

The prefix https://*.example.com/foo doesn't match the following URLs:

  • https://subdomain.example.com/bar (suffix mismatch)
  • https://example.com/foo (at least one subdomain must be present)

Some of the prefix rules are enforced when you try to save your manifest. For example, the following prefixes cause an error if they are present in your manifest when you attempt to save:

  • https://*.*.example.com/foo (multiple wildcards are forbidden)
  • https://subdomain.*.example.com/foo (wildcards must be used as a leading prefix)