rules for Adobe Launch triggers?




Looking at the Adobe Launch API there is a subscription service to register a callback request. the definition of the API reguest can be found here: I really love the idea of registering my own url within those callbacks, mainly because @jexnerW4D wrote a blog about:


the first idea was to expose one of my action to public so that I can be used to register as url in a launch callback. but how to handle "authentication"? and how to prevent somebody else calling my action? I would need to do all the checks about permission within the action itself which seems far too complicated...


having more insights about Firefly and triggers/rules within AIO, I assume that the funcationality of those callbacks are based on the same technology as the Firefly rules. basically it creates sort of a "rule" and invoces an action to call my registered url.


It would be really cool if we could just add a new "rule" to my app manifest.yml listening for defined triggers. is that possible? or any other idea how to invoce one of my action directly to Launch build events (aka triggers)?

Accepted Solutions (1)

Accepted Solutions (1)




Hi @ursboller , thanks for raising this question, a very nice one.

Currently there is no Launch "callback" definition OOTB in Firefly, but we will forward the request to the respective team for consideration.

What you could do for now, is to create a web action as a receiver of this callback. It is public without authentication.

If there is a way that the callback emitter can attach headers, you may leverage the `require-whisk-auth` flag by Openwhisk (on which I/O Runtime is built):

If the callback emitter can not attach headers to the request (looks like the case of Launch callback), how about a simple query param that allows you to check where a request comes from? Something like https://adobeioruntime,net/api/v1/web/guest/my-app/callback?challenge=1234.

It is important that your webhook as a public action only accepts incoming callbacks and does not returns any data. The challenge is useful for filtering legitimate request from Launch and not another source.

There could be other ways of securing webhooks available which require custom implementation.

Answers (0)