The https://URL/SECRET workaround mentioned in Webhooks-Trigger-for-Atlassian-Automation does not seem to work for me in studio.atlassian automations.
The 404 is a good clue since the same endpoint works with <span>X-Automation-Webhook-Token</span>. I’d stick with the header token for Studio for now rather than treating the secret as part of the URL.
<span>X-Automation-Webhook-Token</span>
Unfortunately, this is not always an option to extend headers - even with Atlassian's own Bitbucket webhooks. I would like to know if the advertised workaround is planned to be supported, or if this is merely a bug.
Hi @Beau Herger,
The URL form is in the incoming webhook doc, but its steps only cover the Jira and Confluence rule builder and don't mention Studio. It prefers the header anyway "as it provides more security for your secret", which is Robin's advice.
Only Atlassian can say whether it's planned or a bug. I'd raise it with Atlassian Support, who can confirm it and open a public ticket to watch.
My inference is that Studio has no route for a secret in the path. The Jira endpoint returned 200 for any extra path segment, even on a made-up rule id, so a 404 reads as a missing route rather than a rejected token.
Your header 200 doesn't prove the flow ran either. On a Jira test site even a wrong token got a 200, so the status code tells you nothing. Check the audit log, as this KB for Jira Cloud says.
Bitbucket Cloud only sends its own fixed headers, plus X-Hub-Signature if you set a secret. The trigger doesn't read that one.
For Jira's own webhooks, JRACLOUD-92772 gives the URL form as the workaround. For a Studio flow, a small relay that adds the header is my own suggestion.
It looks like you're new here. Sign in or register to get started.
