Update on Incoming Webhooks Trigger for Atlassian Automation Rules

[#1]

Update Feb 04, 2025

Some of you have encountered challenges with using custom HTTP headers in your applications, particularly when it comes to adding the header X-Automation-Webhook-Token when you send the secret. This may occur if your connected application doesn’t support custom HTTP headers.

If you’re encountering this problem, you can insert a slash at the end of the URL and add the secret after this. For example, https://URL/SECRET. This will allow you to update your rules without the need for a HTTP header. However, we recommend using the header if possible, as it provides more security for your secret.

---

Hey Atlassian Community,

We are updating the incoming webhooks trigger in Atlassian automation. Here’s what it means for your workflows.

What's an incoming webhook and what’s happening to them?

Automation rules can be triggered via incoming webhooks. You can use this trigger to execute a rule by sending a web request from another system, such as a third-party application. In the coming months, rules containing incoming webhook triggers will begin to be routed through a more secure endpoint. This update is part of our continuous focus to uplift the security and reliability of Atlassian automation.

How does this impact me?

Starting today, all new rules created with incoming webhook triggers will automatically be routed through the new endpoint. Any existing rules will continue working as before, however, please note that further action will be required eventually, as these rules will also be routed through the new endpoint in the future.

What happens next?

• We’ll be releasing an update to existing rules with incoming webhooks triggers within the next few weeks - we’ll add information about this to this community post, so keep an eye out for updates!

• Once this update is released, you’ll be able to update your existing rules so that they're routed through the new endpoint. We'll make sure to give you detailed instructions on how to transition your existing rules to the new incoming webhook endpoint, and share further details about the eventual retirement of the current legacy webhooks.

Make sure to check back over the next few weeks for updates!

[Aron Gombas _Midori_]

@Dhanapal Mohanasamy Can you please give a quick hint about how to use the new trigger? (Full documentation would be better, but even a quick hint is better than nothing.)

If it is already rolled out to a site, how can we call the webhook? How should use the new "Secret"?

[Chris Cairns - Digital Rose]

Hi @Dhanapal Mohanasamy    Our app (eSign for Jira) supports integration with automation webhooks and for security reasons the webhook URL is restricted to automation.atlassian.net prefixes.

This security change that was rolled out to production without notice has impacted our customers who received this new security URL (api-private) for webhook triggers.

PLEASE release sufficient information immediately so that we can plan and develop the changes to our app to work with the new security infrastructure.   

Sincerely
Chris C
Digital Rose

[Dhanapal Mohanasamy]

Hi @Aron Gombas _Midori_ , 

Have you checked this page for detailed instructions on using the incoming webhook trigger? If you can't find the information you need, please let us know, and we'll be happy to assist you further. 

[Rick Westbrock]

I was going to ask "what exactly makes the new endpoint more secure than the current endpoint?" but after creating a new rule with a webhook trigger I can see that you buried the lead here: we can finally have a secret for the trigger to prevent unauthorized requests from triggering the rule.

I was glad to see that the documentation (link below) has already been updated to reflect this but why wasn't it mentioned here in this article??

https://support.atlassian.com/cloud-automation/docs/jira-automation-triggers/#Incoming-webhook

[Rick Westbrock]

Since the trigger documentation doesn't mention how  to pass the secret when calling the webhook I found this article https://support.atlassian.com/automation/kb/check-if-the-incoming-webhook-trigger-in-an-automation-rule-is-correct/ which says to pass it in the X-Automation-Webhook-Token header

[Chris Cairns - Digital Rose]

Observation:  We noticed through initial testing that the new webhook returns success (200) for all calls,  whether or not the URL exists and/or the auth token is valid.   

On the Jira Automation Rules audit log side,  no entry is added either (on webhook triggered with missing auth token).

Is this intended behavior? 401 would be much more clear that the required auth token is missing. 

Chris
Digital Rose

[Rick Westbrock]

Ugh, I am sad to hear that HTTP 200 is returned instead of 401. @Chris Cairns - Digital Rose did you happen to notice if the HTTP response body includes any indication of an error or does it just "fail silently"?

I can see why Atlassian might not include details about the error because as I recall I noticed that even with the old endpoint if  you call a URI which doesn't exist (such as when making a typo for the automation rule ID) it returned HTTP 200 (instead of 404) so that a bad actor wouldn't know whether or not they hit a valid endpoint. That security obviously comes at a cost for the "good guys" of making it more difficult to trap errors.

[Chris Cairns - Digital Rose]

UPDATE: As of Jan 28, there is (some) error detection of the token.

Webhook URL response

• 200 OK - When the right token is sent.  Webhook rule triggers in audit log
• 400 Bad Request: ErrorMessages: "Missing token" is returned if the X-Automation-Webhook-Token is not provided
• 200 OK - If the wrong token value is sent.  Webhook rule never triggers, nothing in rule audit log

[Emil Yordanov]

@Dhanapal Mohanasamy

If you're introducing such change you should've at least give the capability to users to set up the name of the authentication tokens for incoming requests because there are third party systems that insist on providing token with their naming and doesn't support setting up anything outside of that.