Hey @Niel-Reitmann
We currently use web triggers to allow our Connect hosting infrastructure to speak to a companion Forge app to share configuration/trigger actions that must be run on Forge in order to access REST APIs or Forge Storage.
Even once those two are merged into the same app, we need to be able to expose our own “REST API” implemented in Forge functions, to other parts of the app that may not be natively hosted on Forge.
Customers ask us for publicly available and documented and secured REST APIs for managing their user-generated content within the app using their own processes and tooling, rather than our web UI within the product within Jira/Confluence. Web triggers is the only option for this in a Forge native world.
I echo @lkimmel’s point that web triggers need a built-in authentication mechanism.
Thanks,
Jon