アトラシアン自動化で受信 Webhook トリガーを設定する

In Atlassian Automation, rules can be triggered with an incoming webhook. You can use this trigger if you want to run 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 more secure endpoint. This update is part of our continuous focus to uplift the security and reliability of Atlassian Automation.

受信 Webhook トリガーを含む新しいルールを作成する

受信 Webhook トリガーを含む新しく作成されたルールはすべて、自動的に新しいエンドポイントを経由します。移行に向けてこれらのルールを準備するために、開発者側で何かする必要はありません。

受信 Webhook を含むルールを作成、設定するには、次の手順を実行します。

1. Jira または Confluence で自動化のルールビルダーを開きます。

2. Select Incoming webhook as your trigger.

3. ルールのアクションと、追加したい条件やブランチを選択します。

4. ルールを有効化します。下書きとして保存して、後で有効化することもできます。

5. これで、トリガー コンポーネントに URL とシークレットが表示されるようになります。

6. その URL とシークレットをコピーします。

7. URL とシークレットを接続先のアプリに入力し、X-Automation-Webhook-Token という名前で新しい HTTP ヘッダーを追加します。これを行う方法はアプリによって異なる可能性があるため、ご利用のアプリの手順をご確認ください。ご利用のアプリでカスタム HTTP ヘッダーがサポートされていない場合、URL の末尾にスラッシュを挿入し、それに続けてシークレットを追加できます。たとえば、https://URL/SECRET のようにします。これにより、HTTP ヘッダーが不要になります。ただし、シークレットのセキュリティ強化のため、可能な場合はヘッダーを使うことをおすすめします。

8. ルールの実行後に監査ログにアクセスすると、URL でルールが正常にトリガーされたかどうかを確認できます。

受信 Webhook トリガーを含む既存のルールを更新する

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.

既存のルールを新しいエンドポイントに移行するには次の手順を実行します。

1. Jira または Confluence で自動化ルールの一覧を開きます。

2. [トリガー] フィルター > [受信 Webhook] フィルターの順に選択します。受信 Webhook トリガーを含むすべてのルールが表示されます。

3. これらのルールのいずれかをルールビルダーで開き、トリガー コンポーネントを選択します。

4. 新しい URL とシークレットをコピーします。

5. 新しい URL とシークレットを接続先のアプリに入力し、X-Automation-Webhook-Token という名前で新しい HTTP ヘッダーを追加します。これを行う方法はアプリによって異なる可能性があるため、ご利用のアプリの手順をご確認ください。ご利用のアプリでカスタム HTTP ヘッダーがサポートされていない場合、URL の末尾にスラッシュを挿入し、それに続けてシークレットを追加できます。たとえば、https://URL/SECRET のようにします。これにより、HTTP ヘッダーを必要とすることなくルールを更新できます。ただし、シークレットのセキュリティ強化のため、可能な場合はヘッダーを使うことをおすすめします。

6. ルールの実行後に監査ログにアクセスすると、新しい URL でルールが正常にトリガーされたかどうかを確認できます。

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

今回の移行では一括アクションを実行することができないため、受信 Webhook トリガーを含むすべてのルールを手動で更新し、接続先のアプリに変更を加える必要があります。

受信 Webhook が機能していることを確認するには

You can perform a quick check by triggering a webhook event and sending a POST request, via cURL or POSTMAN, to check if that triggers your rule. To check with any of the methods below, first:

1. ルールビルダーでルールを開きます。

2. 受信 Webhook トリガーを選択します。

3. Webhook の URL とシークレットをコピーします。

cURL を使用して確認するには次の手順を実行します。

1 2 curl -X POST -H 'Content-type: application/json' -H 'X-Automation-Webhook-Token: <Add you secret here>' \ <Insert_webhook_URL>

Executing the above cURL command in a terminal will return a null. After that, you can check the audit log to see if the rule has run.

POSTMAN を使用して確認するには次の手順を実行します。

1. リクエスト タイプを POST に変更します。

2. Webhook の URL を URL セクションに貼り付けます。

3. X-Automation-Webhook-Token というヘッダーと、シークレットに設定された値を指定します。

4. Select Send.

5. [ステータス] に、POST リクエストが成功したことを示す 200 応答コードが表示されるはずです。

6. 自動化の監査ログで、ルールが正常に実行されたことを確認します。

上記の方法のいずれかを使用してルールがトリガーされた場合、受信 Webhook コンポーネントが想定どおりに機能していることになります。

We’ll release further updates over the next few months, which will make it easier for you to prepare for this upcoming change. These will be announced via email, community post and release notes. Information about these updates will also be added to this page once they’re available. In the meantime, if you’d like further assistance, you can contact support.