Update on Incoming Webhooks Trigger for Atlassian Automation Rules

[#1]

Update Mar 7, 2025

We’ve added a new feature to Atlassian Automation to help you easily identify rules that were recently triggered through a legacy incoming webhook. For existing rules with incoming webhook triggers to continue working after May 30, 2025, you’ll need to make updates in the connected applications which trigger them.

Rules recently triggered through legacy webhooks will now be marked with warning icons

To view this new feature:

1. Open the automation rule list in Jira or Confluence.

2. Click on the ‘Trigger' filter and select the ‘Incoming webhook’ filter. All rules triggered by an incoming webhook will be shown. These rules need to be updated before May 30, 2025.

3. Within these filtered rules, any which have recently been triggered through a legacy webhook will have a warning icon next to their name. This shows which rules are actively using the legacy URL.

4. To learn how to update these rules, you can read our support documentation.

Please note - the warning icon will continue to be shown 14 days after the rule was last triggered through the legacy endpoint, even if you have updated your rule. The icon, and other related warnings, will disappear once 14 days has passed without the rule being triggered through the legacy webhook. You can confirm when your rule was last triggered by viewing the ‘latest call’ timestamp next to the legacy URL.

If you have already made updates in your connected application to use the new endpoint, but there are still requests coming through the legacy endpoint, this may indicate there’s more than one application using the webhook trigger in the same rule. You can confirm if this is has happened by looking at the ‘latest call’ timestamp next to both the legacy and new URLs. In this case, find all the applications connected to your rule and replace the URL and secret in all of them.

---

Update Feb 07, 2025

We’ve just shipped an update to existing rules with an incoming webhook trigger. You’ll now be able to prepare for our migration to the new incoming webhooks system.

How does this impact me?

As specified in our previous announcement, all new rules that contain an incoming webhook trigger will automatically be routed through the new endpoint.

Rules created before 28 January 2025 will work normally until 30 May 2025, however for these rules to continue working after this date, you'll need to make the changes in the applications to migrate to the new endpoint. The legacy endpoint will no longer be available to trigger your rules as of 30 May 2025.

How do I migrate to the new endpoint?

1. Open the Automation rule list in Jira or Confluence.

2. Click on the ‘Trigger' filter and select the ‘Incoming webhook’ filter. All rules containing an incoming webhook trigger will be shown.

3. Open one of these rules in the rulebuilder and select the trigger component.

4. Copy the new URL and secret.

5. Enter the new URL and secret into your connected application, and add a new HTTP header with the name X-Automation-Webhook-Token. The method to do this can vary between applications, so you may need to check what the instructions are for your application. If your application does not support custom HTTP headers, you can instead 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.

6. You can verify if the new URL successfully triggered your rule by visiting the audit log after it runs.

7. Repeat the above steps for all rules containing an incoming webhook trigger.

FAQs

Why can’t Atlassian automatically update my rules to use the new incoming webhook trigger?

Since the incoming webhooks may be called from non-Atlassian systems that we don’t have access to or aren’t aware of, rule owners will need to migrate them manually.

I use webhooks to chain my automation rules. Do I need to make changes to those too?

Yes. If you use the “Send web request” action in a rule, which triggers another rule containing the incoming webhook trigger, you'll need to update the endpoint used in the “Send web request” action.

What happens after the deprecation notice period ends?

The rules will no longer trigger through legacy incoming webhooks after 30 May 2025. Make sure that you've updated all of your rules containing incoming webhook triggers before this date.

Read documentation about the upcoming changes to incoming webhooks in Atlassian Automation

---

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.

[Paul Madison]

You have to use X-Automation-Webhook-Token in the header with the Secret token to use the new Incoming Webhooks.

[Daniel Szewczyk]

Another hastily implemented change that shows that Atlassian doesn't care about its users and admins...

In the rule list view there is no way to filter out rules that are triggered with webhook.
We have thousands of those so it will mean weeks of work to go through all the rules manually. Somehow this filtering can be done as it's available on the audit log (but it's not useful in this case as we can't sift through thousands of executions to find some rarely executed rules with this type of trigger).

Forced secret value that you can't change - won't even comment on that one...

Start fixing old bugs and stop implementing useless, ill-considered changes that make our lives harded and harder!

[Rudy Holtkamp]

@Dhanapal Mohanasamy , will the token also expire after one year?

I'm asking this, because I also see this article about expiry of (API) tokens.

[Darryl Lee]

@Daniel Szewczyk there is a link in the Update message that says "View rules" seems to filter out rules that contain incoming webhooks. Here's my Confluence automations:Maybe the ability to filter by Trigger is newly added?

It looks like all the Triggers are there. This is from my Jira:

[Thomas Kekeisen]

Very hard to understand where the original article begins and what all the updates are.