Do Editor add-on trigger limits (hourly minimum, one per type per user per doc) apply to triggers created by a web app deployment in the same script project?

Google Workspace Developers Q&A
,
1

I have a single Apps Script project with two deployments, bundled in one Google Workspace Marketplace listing per the “List app integrations together” documentation:

  1. A Sheets Editor add-on (HtmlService dialogs, container-bound behavior).
  2. A web app deployment with executeAs: USER_ACCESSING, so it runs under the identity of the accessing user with their authorization.

The docs state two restrictions for add-ons:

  • “An add-on can use a time-driven trigger once per hour at most.” (apps-script/guides/triggers/installable)
  • “Each add-on can only have one trigger of each type, per user, per document.” (workspace/add-ons/concepts/editor-triggers)

My server code creates installable triggers programmatically, e.g.:

ScriptApp.newTrigger('continueJob_').timeBased().after(5 * 1000).create();
// or
ScriptApp.newTrigger('syncTick_').timeBased().everyMinutes(5).create();

Questions:

  1. Do the add-on trigger restrictions attach to (a) the script project as a whole, (b) the add-on deployment specifically, or (c) the execution context that created the trigger?
  2. Concretely: if ScriptApp.newTrigger(...) runs inside a web app execution (executeAs: USER_ACCESSING) in a project that ALSO has a published Editor add-on deployment, is that trigger subject to the add-on caps (>= 1 hour, one per type per user per document), or to the standard installable-trigger rules (everyMinutes(1/5/10/15/30) allowed, 20 triggers per user per script)?
  3. Does sharing a single Marketplace listing between the add-on and the web app change the answer?

Has anyone run this multi-integration pattern (Editor add-on + user-executing web app, one listing) in production and observed which trigger rules actually apply to triggers created from the web-app path?

1 Like