When triggering a triggered automation through the trigger URL (see the endpoint below), the execution token must be sent as a header parameter. Currently, it is possible to send the execution token as a query parameter. Starting February 1st, 2026, sending execution tokens as header parameters will be enforced.
api/v1/automations/{id}/actions/execute
Any Button objects using the built-inRun Automation feature are not affected by this change.
Don't hesitate to reach out if you have any questions or address our experts directly in the Qlik Automate forum.
Surely this change is going to break anywhere that an automation is started from a webhook simply called as a URL?
If so, this is going to stop the ability to start automations from a number of third party automations, such as IFTTT. I have blogged a few times on using this as a technique, and I would imagine it is quite widely used. I certainly make use of it with a number of different client tenants.
I also use it to start tasks from buttons within Qlik Sense, from before when it was possible to start automations from a button natively.
I hope that this change gets postponed again, at least until such time a switch is added to the Start block which then allows the header to be passed as a parameter, to allow calls from browser favourites and IFTTT etc.
Correct, we will no longer support passing it in the URL like `mytenant.us.qlikcloud.com/api/v1/automations/1234/actions/execute?X-Execution-Token=1234` as this falls foul of industry guidance on how to handle sensitive tokens.
I had a quick look at our code and it appears we migrated our native button objects to use the header back in 2024, so if you're seeing calls from our native buttons causing issues it'd be good to hear more about that specific issue. If it's your custom extensions, these do need to be updated, although it would be a very simple change that I could provide some guidance on.
For IFTTT, I had understood they now support custom headers, if you can provide further information on which actions you're using and their limitations, I will take a closer look.
For browser favourites, you'd have to use a bookmarklet instead. This probably provides a better user experience though as you can handle the look and feel on click rather than it being a hanging page without feedback. I created a simple generator for bookmarklets here in case you want to see what that could look like: https://withdave.github.io/qlik/automate-bookmarklet-generator.html
Yesterday, an email notification was sent to the Service Account Owners of all tenants which sent a request with an execution token sent as a query parameter within the past 7 days. This means that all customers and partners with a valid SAO email account linked to their tenant will have a direct notification in their inbox informing them of the automation ID(s) they need to adapt their usage of.
The buttons are ones that would have been created back before 2024 and firing an automation from a button had no native support. Most of these I have updated, but I can imagine that there will be some clients we are no longer actively engaged with that could still have that code in place.
Where I am kicking off automations from within a load script (which I tended to do before reload chaining was a thing in Cloud) then I've seen it's a simple case of adding a HTTPHEADER into the WITH CONNECTION block, so that is fine.
I've checked IFTTT, and you are correct, headers can be added to POST type calls, so that is all good. It is also possible to build a relay using a webhook trigger and target in IFTTT to take the parameter and pass it on as a header - but that kind of defeats the object of not using headers.
Your bookmarklet generator is very elegant. I can see that I will be using that, to replace the bookmarks that I have helped clients set up. Will those export and import correctly between browsers, if I set them up on my machine and then create a file for other users to import?
I built a simple JavaScript relay, to take in parameters and then send them on as headers then give a pretty output, but bookmarklets seem the way to go.
Thanks for the confirmation on the button, understood. Hopefully the email outreach will reach those who don't have coverage and we can get those patched, at this point it's not too many with a configuration of that sort.
Yes! Bookmarklets have a special place in my heart for their portability as small mega-powerful buttons in a browser. I've done many a terrible thing with a bookmark and a Qlik UI...
I've put together a blog post on the various ways of ensuring this change doesn't cause issues, including using @Dave_Channon's excellent bookmarklet creator. You can find it here:
